意向锁（is/ix）是innodb自动加的表级轻量标记，用于避免表锁检查时逐行扫描行锁；is由select lock in share mode触发，ix由select for update、update、delete、insert自动触发，二者互不阻塞但均与表级write锁冲突。
意向锁不是你加的，是InnoDB自动加的
你写 SELECT ... FOR UPDATE 或 UPDATE，InnoDB 就会在对应表上自动加 IX 锁；写 SELECT ... LOCK IN SHARE MODE，就自动加 IS 锁。你没法手动 LOCK TABLE ... IN INTENTION SHARE MODE —— 语法根本不存在，也不允许显式操作。
它的存在不是为了让你“用”，而是让 InnoDB 在加表锁（比如 LOCK TABLES t WRITE）时，能跳过全表扫描行锁状态这个昂贵操作。只要看到表上有 IS 或 IX，就知道“有人正在读/写某些行”，直接阻塞表锁请求即可。
-
IS和IX之间完全兼容，多个事务可同时持有 -
IS与表级READ锁兼容，但与WRITE锁冲突 -
IX与任何表级锁（READ/WRITE）都冲突 - 意向锁生命周期 = 事务生命周期，
COMMIT或ROLLBACK后自动释放
查不到意向锁？试试 performance_schema.data_locks
老版本用 SHOW ENGINE INNODB STATUS 看锁信息，但输出杂乱、不易解析，且只显示最近一次死锁或部分活跃锁。MySQL 5.7+ 推荐用 performance_schema.data_locks 表实时查：
SELECT object_schema, object_name, index_name, lock_type, lock_mode, lock_data FROM performance_schema.data_locks WHERE object_name = 'your_table_name';
注意几个关键字段含义：
-
lock_type = 'TABLE'且lock_mode含IS或IX→ 就是意向锁 -
lock_type = 'RECORD'→ 行锁（S或X） -
lock_data显示具体锁定的主键值（如1）或范围（如min, 5） - 同一事务可能同时出现
TABLE+RECORD多条记录，别漏看
LOCK TABLES ... WRITE 被卡住？先看有没有 IX
典型现象：执行 LOCK TABLES t WRITE 一直阻塞，SHOW PROCESSLIST 显示 Waiting for table metadata lock —— 这不是元数据锁（MDL）问题，很可能是表上有未提交事务持有了 IX 锁。
排查步骤：
- 查
performance_schema.data_locks，确认t表是否存在lock_mode = 'IX'的TABLE锁 - 用
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = ?找到对应事务的THREAD_ID - 再查
performance_schema.events_transactions_current，看该线程事务是否STATE = 'ACTIVE'且未提交 - 不要直接 kill，先确认业务逻辑——那个
UPDATE是不是忘了COMMIT？
特别注意：IX 锁本身不阻塞其他 DML（比如另一个 UPDATE 仍可加自己的 IX），但它会阻塞所有表级 WRITE 和 READ 锁。这是设计使然，不是 bug。
为什么 SELECT ... FOR UPDATE 没锁表却影响了 LOCK TABLES？
很多人以为“没改数据就不该阻塞表锁”，但只要执行了 SELECT ... FOR UPDATE，InnoDB 就已加了 IX 锁 —— 即便最终没找到匹配行（WHERE id = 999 不存在），IX 依然被加上并持续到事务结束。
这种“空操作加意向锁”的行为容易被忽略，导致：
- 开发测试时随手写个
FOR UPDATE查数据，忘记COMMIT，结果线上运维要加表锁备份时被卡住 - ORM 自动生成的查询带
FOR UPDATE（比如某些“悲观锁”封装），在事务外调用后未清理 -
IX锁不显示在慢日志里，也不报错，只默默挡住表锁操作
真正难排查的，从来不是锁住了哪一行，而是那个什么都没改、却悄悄锁住了整张表“意图”的 IX。
