锁粒度的并发度开销权衡与意向锁机制

锁加在多大的对象上（整个数据库、一张表、还是一行数据）是一个纯粹 的权衡问题：粒度越大（如给整个数据库加锁），系统只需要维护和检查 少数几把锁，管理开销小，但任何其他事务只要碰这个数据库的任何数据 就要排队等待，并发度极低；粒度越小（如只锁单条记录），并发度高 （不同事务操作不同记录互不干扰），但每次操作都要申请释放大量的锁， 管理开销显著上升。因此系统通常支持多粒度锁，让事务按实际需要处理 的数据规模选择合适的锁粒度。多粒度锁引入了一个新问题：如果事务A 给整个数据库加了读锁，事务B想给某张表的某条记录加写锁，系统必须 知道”这条记录其实已经被数据库这一层的锁间接覆盖了”（隐式锁）， 但如果每次加锁都要逐层检查所有上级和下级节点的锁状态，检查本身 的开销会很大。意向锁就是为了简化这个检查过程而设计的：给一个节点 加锁前，必须先给它所有的上级节点加上意向锁，意向锁本身不直接锁住 数据，只是标记”我的某个下级节点将要加某类锁”——这样系统只需要 检查目标节点及其直接上级链上的意向锁标记，不需要遍历整棵粒度树的 所有节点，就能快速判断是否存在冲突。这套”细粒度实际加锁+沿途留下 意向标记”的设计，本质上是用一点点额外的标记开销，换取了原本需要 遍历检查的巨大开销，是多粒度锁系统能在实践中真正落地的关键。

结构图：

flowchart TD
    A[锁粒度选择] --> B[粒度越大: 管理开销小, 并发度低]
    A --> C[粒度越小: 并发度高, 管理开销大]
    D[多粒度锁的检查难题] --> E["细粒度实际加锁<br/>(如单条记录加X锁)"]
    D --> F["沿途上级节点加意向锁<br/>(IS/IX/SIX, 只是标记不直接锁数据)"]
    E --> G[新申请只需检查目标节点<br/>及其上级意向锁标记]
    F --> G
    G --> H[避免遍历整棵粒度树逐一检查]