意向锁是sql数据库实现多粒度锁的关键机制，用于在表、页、行等层级间高效协调并发访问，通过IS、IX、SIX等轻量级预告锁避免逐层检查冲突，提升锁管理效率。
意向锁（Intent Lock）是SQL数据库实现多粒度锁（Multi-Granularity Locking）的关键机制，用于高效协调不同层级（如表、页、行）上的并发访问，避免加锁时逐层检查冲突，显著提升锁管理效率。
为什么需要意向锁？
在支持多粒度锁的系统中，事务可能在不同层级上加锁：比如对整张表加共享锁（S），或仅对某几行加排他锁（X）。若没有意向锁，当一个事务想对某一行加X锁时，系统必须遍历该表所有已存在的锁，确认没有与之冲突的表级S锁——这开销极大。意向锁作为“轻量级预告”，提前声明“我将在下层加某种类型的锁”，让高层锁检查变成一次快速判断。
常见意向锁类型：
- IS（Intent Shared）：表示事务打算在子节点（如下级页或行）加S锁；
- IX（Intent Exclusive）：表示事务打算在子节点加X锁；
- SIX（Shared with Intent Exclusive）：已在本层加S锁，同时计划在下层加X锁（例如读全表+更新某几行）。
多粒度锁的兼容性规则
意向锁本身不排斥数据访问，其核心作用是参与锁兼容性判断。系统维护一张兼容性矩阵，关键规则包括：
- 表级S锁与IS、IX、SIX都不兼容（因为S锁要求整个表只读，而IX/SIX预示将修改子项）；
- 表级X锁与任何意向锁都不兼容（X锁独占整表，不允许任何下层操作）；
- IS与IS、S、SIX兼容；IX与IX、SIX兼容；但IS与IX互不兼容（防止读写混杂导致逻辑混乱）。
实际加锁流程中，事务需自上而下申请：先获得表级意向锁（如IX），再申请行级X锁；释放时则相反，确保语义一致。
典型场景与锁升级/降级示意
意向锁天然支持锁粒度动态调整。例如：
- 事务初始扫描全表（加IS），随后定位到3行需更新 → 升级为IX（表级）+ X（3个行锁）；
- 事务先更新单行（加IX + X），后决定更新全表 → 可尝试将IX升级为X，但需等待所有现有行锁释放且无其他IS/IX阻塞；
- 若持有SIX锁的事务只读取未修改的行，后续可安全降级为S锁（前提是确认下层无活跃X锁）。
注意：锁升级需满足兼容性，且多数数据库（如SQL Server、postgresql）默认不自动升级，需显式控制或依赖优化器策略。
设计建议与常见误区
在应用层或存储过程设计中，合理利用意向锁能减少死锁、提升吞吐：