MySQL 的意向锁（Intention Locks）原理详解
1. 背景：为什么需要意向锁？
MySQL 中意向锁的主要作用是用于支持行级锁与表级锁的并存，特别是在 InnoDB 存储引擎中。InnoDB 提供了行级锁，而在某些场景下，数据库系统仍需要对整张表加锁，例如 LOCK TABLES 或 ALTER TABLE 操作。在这些场景中，如果没有意向锁机制，系统需要扫描所有行级锁来判断是否可以安全地加表锁，这会严重影响性能。
为了解决这一问题，意向锁应运而生。意向锁是一种表级锁，用于指示事务将要或已经在某些行上加锁。它通过提供表级的锁定信息，避免了系统去逐行检查是否可以加表锁。
2. 意向锁的类型
InnoDB 支持两种类型的意向锁：
- 意向共享锁（IS, Intention Shared）：事务想要在表中加共享锁之前，必须先获得意向共享锁。
- 意向独占锁（IX, Intention Exclusive）：事务想要在表中加排他锁之前，必须先获得意向独占锁。
共享锁（S 锁）：允许读取但不允许修改数据。
排他锁（X 锁）：允许读取和修改数据，并阻止其他事务加任何锁。
3. 意向锁的工作机制
意向锁的工作机制体现在事务与行级锁以及表级锁的协作上：
- 当事务对表的某些行加行级锁时，它会先申请表级的意向锁（IS 或 IX），以告知其他事务该表上有行级锁存在。
- 如果一个事务想要加表级的锁，它首先需要确认没有其他事务持有相冲突的意向锁或行锁。
例如：
- 一个事务在表的某行上加了行级排他锁（X 锁），则必须先获得意向独占锁（IX）。如果另一个事务尝试给整张表加共享锁（S 锁），这个操作将会失败，因为 IX 锁与 S 锁冲突。
- 反之，如果某事务只想对表的某些行加共享锁（S 锁），则它会申请意向共享锁（IS）。如果没有其他事务持有排他锁（如 X 锁），操作即可执行。
通过意向锁，MySQL 在表级别快速判断是否可以加锁，而无需遍历行锁，极大提高了加表锁的效率。
4. 意向锁与其他锁的兼容矩阵
InnoDB 中各种锁之间的兼容性决定了锁冲突的可能性。下表展示了意向锁与其他锁之间的兼容性关系：
| IS | IX | S | X | |
|---|---|---|---|---|
| IS | ✔ | ✔ | ✔ | ✖ |
| IX | ✔ | ✔ | ✖ | ✖ |
| S | ✔ | ✖ | ✔ | ✖ |
| X | ✖ | ✖ | ✖ | ✖ |
- ✔ 表示兼容，允许同时存在。
- ✖ 表示不兼容，不能同时存在。
5. 源代码层面的实现
在 MySQL 的 InnoDB 存储引擎中，意向锁的实现主要体现在锁管理和事务管理模块中。我们从源码中进行分析：
5.1 锁管理模块
InnoDB 的锁管理模块位于 lock0lock.cc 文件中，主要函数有：
lock_rec_lock()：负责加行级锁，包括排他锁（X 锁）和共享锁（S 锁）。在加锁之前，会先判断是否需要获取意向锁。lock_table()：负责加表级锁，其中也涉及到意向锁的获取过程。
5.2 意向锁的加锁过程
在加行级锁时，MySQL 首先会根据事务需要加的锁类型来决定是否需要意向锁。假如事务需要在某行上加 X 锁（排他锁），系统会首先调用 lock_table() 来尝试给对应表加 IX 锁（意向排他锁）。如果意向锁冲突，则表明另一个事务已经持有冲突的锁（例如，另一个事务持有 S 锁），加锁失败。
相关源码逻辑如下：
bool lock_table(dict_table_t* table, // 要加锁的表ulint type, // 锁的类型（X 锁、S 锁、IX 锁、IS 锁等）trx_t* trx // 当前事务
) {// 加锁过程，判断当前表是否已持有冲突的锁if (type == LOCK_IX || type == LOCK_IS) {// 检查是否存在冲突的锁，涉及到 IX 和 IS 的兼容性// 如果可以加锁，则加锁成功}return success;
}
5.3 锁兼容性检查
意向锁与其他锁的兼容性通过 lock_mode_compat() 函数进行判断。该函数用于确定两种锁类型是否兼容，是否可以同时存在。
例如，IX 锁与 S 锁之间是互斥的，因此在加锁时会检查 IX 锁是否与现有的锁冲突：
bool lock_mode_compat(ulint mode1, // 第一个锁的类型ulint mode2 // 第二个锁的类型
) {if ((mode1 == LOCK_IX && mode2 == LOCK_S) || (mode1 == LOCK_S && mode2 == LOCK_IX)) {// IX 锁与 S 锁冲突，返回不兼容return false;}// 其他兼容性检查逻辑return true;
}
5.4 表级锁与行级锁的协作
当事务对某行进行加锁操作时，会先调用表级的意向锁机制，表级的意向锁通过 lock_table() 函数处理，而行级锁则通过 lock_rec_lock() 实现。加锁顺序为：
- 检查是否已经持有相应的意向锁，如果没有，则先申请意向锁。
- 然后再申请具体行的锁。
bool lock_rec_lock(ulint type, // 锁的类型dict_index_t* index, // 行所在的索引const buf_block_t* block,// 行所在的块ulint heap_no, // 行的索引号trx_t* trx // 当前事务
) {// 如果需要意向锁，则首先调用 lock_table() 加表锁if (need_intention_lock(type)) {if (!lock_table(index->table, LOCK_IX, trx)) {return false; // 加表意向锁失败}}// 接下来加行级锁// 锁管理器会检查是否与现有的行锁冲突return lock_rec_add_to_queue(type, block, heap_no, trx);
}
6. 意向锁在事务中的表现
事务在获取行级锁时，首先获取表级的意向锁，只有在表级意向锁不与其他事务冲突时，行级锁才能继续加上。这种机制保证了行级锁与表级锁之间的有效协调，从而避免了事务之间的冲突。
总结：
- 意向锁是为了提高 MySQL 锁管理效率而设计的，允许 MySQL 在表级快速判断是否可以加锁。
- 两种意向锁类型：意向共享锁（IS）和意向独占锁（IX），用于表示事务想要加的行级锁类型。
- 源码实现表现在
lock_table()和lock_rec_lock()等函数中，意向锁通过检查锁的兼容性确保事务在行级和表级加锁的正确性。 - 意向锁的作用是避免在加表锁时遍历所有行锁，从而大幅提高系统性能。
通过意向锁，MySQL 能有效地管理复杂的锁冲突场景，特别是在行级锁和表级锁同时存在时提供了明确的锁定层次，防止冲突并保持高效的锁操作。