意向锁是InnoDB自动加的表级标记，用于避免加表锁时逐行扫描检查行锁，极大提升冲突检测效率；IS锁由SELECT...LOCK IN SHARE MODE触发，IX锁由INSERT/UPDATE/DELETE/SELECT...FOR UPDATE触发。
为什么表锁检查要查意向锁，而不是直接扫行？
因为逐行检查有没有行锁太慢。一张千万级的表，加个 LOCK TABLES t WRITE，如果真去遍历每一行看是否被 SELECT ... FOR UPDATE 锁住，光锁检测就可能卡住几秒甚至更久。意向锁就是这个瓶颈的解法：它不锁数据，只在表级别打个“标记”，告诉其他事务“这里已经有行级操作在进行了”。IS 或 IX 本身不阻塞任何行操作，但能立刻让表锁请求失败或通过。
IS锁和IX锁分别由什么语句触发？
意向锁是自动加的，你不用显式写，但必须清楚谁会带出它：
-
SELECT ... LOCK IN SHARE MODE→ 自动加IS锁（同时对命中行加 S 锁） -
INSERT、UPDATE、DELETE、SELECT ... FOR UPDATE→ 自动加IX锁（同时对命中行加 X 锁） - 没走索引的 DML（如
UPDATE t SET a=1 WHERE b='x'，而b无索引）→ 仍加IX，但会为全表每行都加 X 行锁，效果等同于“伪表锁”
IS/IX锁与表锁的兼容性怎么判断？
关键不是看“意向锁之间是否冲突”，而是看“意向锁是否允许你加目标表锁”。InnoDB 的兼容矩阵本质就两条：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
IS允许加LOCK TABLES t READ（读锁），但拒绝LOCK TABLES t WRITE（写锁） -
IX拒绝所有表锁：READ和WRITE都会被阻塞 -
IS和IX彼此不互斥——多个事务可以同时有IS和IX并存，这正是高并发的基础
验证方式：执行 SELECT object_schema,object_name,lock_type,lock_mode FROM performance_schema.data_locks，能看到 TABLE 类型的锁记录中 lock_mode 是 IS 或 IX。
容易被忽略的实战陷阱
意向锁本身不造成阻塞，但它的存在暴露了背后真正的瓶颈：
- 看到
IX锁长期存在，别只盯意向锁——要立刻查对应事务是否没提交、是否在做慢查询、是否锁了不该锁的范围（比如没走索引） -
IS锁允许表读锁，但不代表安全：多个SELECT ... LOCK IN SHARE MODE可能互相阻塞在行级 S 锁上，尤其在 RR 隔离级别下叠加间隙锁时 - 监控时只看
data_locks不够，得结合INFORMATION_SCHEMA.INNODB_TRX查事务状态，否则你以为是意向锁问题，实际是某个事务 hang 在了网络超时或应用层未 commit
