意向锁是InnoDB自动加的表级路标（IS/IX），用于让表锁快速判断行锁冲突，避免全表扫描；它由行操作触发、与表锁冲突但彼此兼容，且仅能通过performance_schema.data_locks查看。
意向锁不是你手动加的，是InnoDB自动打的“表级路标”
意向锁（IS 和 IX）根本不是你写 SQL 时能显式申请的锁。它由 InnoDB 在执行行级操作前自动加在表上，目的只有一个：让后续想加表锁的事务能「秒判」冲突，不用扫全表。
常见错误现象是看到 LOCK TABLES t WRITE 卡住几秒，或者 SELECT ... FOR UPDATE 后另一个会话尝试加表锁被阻塞，却查不出谁在锁——其实背后就是意向锁在起作用。
关键点：
-
IS锁由SELECT ... LOCK IN SHARE MODE触发，表示“我正准备/已经对某些行加共享锁” -
IX锁由UPDATE、DELETE、SELECT ... FOR UPDATE触发，表示“我正准备/已经对某些行加排他锁” - 意向锁之间完全兼容（
IS和IX可共存），但它们和真正的表级S或X锁冲突 - 你永远无法用
LOCK TABLES或SELECT ... FOR UPDATE手动获取IS/IX，它们纯属引擎内部协调机制
为什么检查表锁要查意向锁，而不是直接扫行？
假设一张表有 800 万行，事务 A 刚给其中一行加了 X 行锁。此时事务 B 执行 LOCK TABLES t WRITE，数据库必须确保“这张表没被任何行锁占用”，否则会破坏一致性。
如果没有意向锁，InnoDB 唯一办法就是遍历全部 800 万行，逐个检查每行有没有 X 或 S 行锁——这在高并发下极易造成秒级延迟甚至超时。
有了意向锁后：
- 事务 A 加行锁前，先快速获得表级
IX锁（开销极小） - 事务 B 请求表级
X锁时，只查一次表元数据：发现已有IX，立刻判定冲突，进入等待 - 整个过程是 O(1)，不是 O(N)
IS/IX 锁不阻塞行操作，但会真实影响表锁行为
很多人误以为意向锁“没用”，因为它不阻止其他事务继续读写行。但它对表锁的影响是刚性的：
- 当表上存在
IS锁时，LOCK TABLES t WRITE会被阻塞（因为IS和表级X不兼容） - 当表上存在
IX锁时，LOCK TABLES t READ也会被阻塞（因为IX和表级S不兼容） - 你可以用
SELECT * FROM performance_schema.data_locks查到LOCK_DATA为NULL、LOCK_MODE含IS或IX的记录，确认意向锁存在 - 意向锁生命周期严格绑定事务：只有
COMMIT或ROLLBACK后才释放，长事务会一直持有它
容易被忽略的实战坑点
意向锁本身不难理解，但线上问题往往出在它和别的锁机制的叠加效应上：
- 无索引查询触发全表扫描 + 行锁 → 大量
IX锁堆积，导致后续任何表锁请求都卡住（不是死锁，是锁等待） -
ALTER TABLE需要元数据锁（MDL），而MDL获取前会检查意向锁；若此时有长事务持IX，ALTER就会挂起，且SHOW PROCESSLIST只显示Waiting for table metadata lock，看不到根源 - 备份工具如
mysqldump --single-transaction依赖 MVCC，但如果备份期间有 DDL 操作，可能因MDL等待被意向锁间接拖慢 -
INFORMATION_SCHEMA.INNODB_TRX不显示意向锁，必须查performance_schema.data_locks才能看到
真正麻烦的从来不是意向锁本身，而是它把行锁的存在「广播」给了整个表层逻辑——这个信号一旦被长事务、DDL、备份等场景捕获，就会放大成系统级阻塞。查锁别只盯着行，先看表级意向状态。
