索引锁在PostgreSQL中由DML或DDL操作触发，用于保护索引结构一致性，结合MVCC和轻量锁实现高并发。
PostgreSQL 的索引锁和并发模型设计旨在支持高并发访问的同时保证数据一致性。理解索引锁的产生机制以及底层并发控制原理，有助于优化查询性能、减少锁冲突。
索引锁是如何产生的
在 PostgreSQL 中，索引锁并不是独立于数据行锁存在的，而是随着对表和索引的操作，在执行 DML（INSERT、UPDATE、DELETE）或某些 DDL 操作时自动触发。
当一个事务修改数据时，系统需要更新对应的索引条目以保持一致性，这就涉及到对索引结构的访问控制。为了防止多个并发事务同时修改同一个索引页导致结构损坏或读取到不一致的状态，PostgreSQL 使用索引级别的锁来协调访问。
常见触发索引锁的场景包括：
- INSERT 操作：向表中插入新行时，需要在相关索引中添加新的键值，此时会申请索引上的锁（如 SIRead 或 S/IX 锁），确保没有其他事务正在重构该索引。
- UPDATE/DELETE 操作：修改或删除已有记录时，不仅要锁定表中的行，还要修改旧的索引项并可能插入新的索引项，因此会对涉及的索引页加锁。
- 索引重建或创建：使用 CREATE INDEX CONCURRENTLY 时，为了避免阻塞写操作，采用更细粒度的锁定策略，但仍会在特定阶段获取索引锁以完成元数据变更。
需要注意的是，PostgreSQL 并不会为每个索引操作都显式持有长时间的“索引锁”，大多数情况下是通过轻量级的内部锁（如 buffer pin 和 LWLock）保护共享内存中的索引页，而高层的锁模式主要体现在锁兼容矩阵中与表锁协同工作。
PostgreSQL 索引的并发控制模型
PostgreSQL 使用多版本并发控制（MVCC）作为核心并发机制，这一机制同样影响索引的访问方式。索引本身并不存储事务可见性信息，它只是指向堆表中具体的元组（tuple）。因此，索引扫描必须结合 Heap Tuple 的事务状态判断是否可见。
这种设计带来了以下特点：
- 索引扫描仍需回表检查可见性：即使通过索引找到了匹配的 TID（块号+偏移量），也必须去堆表中查看该 tuple 是否对当前事务可见（依据 xmin/xmax 和事务快照）。
- 减少索引层的锁竞争：由于索引条目不参与 MVCC 判断，多个事务可以并发读取同一索引页而无需互斥，仅在修改索引结构时才需要加锁。
- Hot Standby 上可执行只读查询：备库上的查询可通过索引进行查找，但遇到被删除但尚未 vacuum 的不可见行时会跳过，这依赖于主库传递的 WAL 日志和一致性视图。
对于写操作之间的并发控制，PostgreSQL 在索引级别采用了基于 B-tree 结构的优化技术，例如：
- WAL Logging for Indexes：所有索引更改都被写入 WAL，支持崩溃恢复和流复制。
- FPI（Full Page Writes）保护索引页：确保在检查点之后的页修改能安全恢复。
- B-Tree 的并发算法改进：从 9.2 版本开始引入了“superlocking”减少锁争用；后续版本逐步增强为基于原子操作和轻量锁的高并发 B-tree 实现，允许读写、写写操作在不同分支上并行进行。
如何降低索引锁带来的影响
虽然 PostgreSQL 的索引并发能力较强，但在高并发写入场景下仍可能出现锁等待或性能瓶颈。可以通过以下方式缓解：
- 避免频繁更新索引列：尤其是主键或唯一索引字段的大批量 UPDATE，会导致大量索引重写和锁开销。
- 合理使用部分索引或覆盖索引：减少不必要的索引维护，也能降低锁范围。
- 使用非阻塞方式创建索引：CREATE INDEX CONCURRENTLY 可避免长时间表锁，适合生产环境在线添加索引。
- 监控锁等待情况：通过 pg_locks 和 pg_stat_activity 查看是否有因索引操作引起的锁等待。
基本上就这些。PostgreSQL 的索引锁是在实际修改索引结构时由内部机制自动管理的，其并发模型依托于 MVCC 和精细化的锁层次结构，能够在多数场景下实现良好的并发性能。
