意向锁（IS/IX）是InnoDB自动加的表级标记锁，本身不阻塞操作；真正阻塞发生在后续显式表锁（如LOCK TABLES ... WRITE）或DDL（如ALTER TABLE）申请时，因MySQL检测到IS/IX而拒绝加X表锁或MDL写锁。
意向锁本身不阻塞，阻塞发生在表锁申请阶段
意向锁（IS / IX）是InnoDB自动加的表级“标记锁”，它自己从不直接阻塞任何操作。真正发生阻塞的，是后续对LOCK TABLES ... WRITE或ALTER TABLE这类显式表锁的申请。MySQL检查到目标表上已有IS或IX，就拒绝加X表锁——因为这意味着有其他事务正在读或写该表的某些行。
为什么SELECT ... FOR UPDATE会触发IX但不阻塞普通查询
执行SELECT ... FOR UPDATE时，InnoDB必须先在表上加IX锁，再给命中的行加X行锁。这个IX只和表级X锁冲突，不影响其他事务的SELECT（靠MVCC）、也不影响其他事务对**不同行**的FOR UPDATE（只要没间隙锁重叠）。常见误解是“加了IX就卡住了整张表”，其实不会。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
IX与IS、IX之间完全兼容，多个事务可同时持有 -
IX与表级S锁冲突（LOCK TABLES t READ会被阻塞） -
IX与表级X锁冲突（LOCK TABLES t WRITE会被阻塞）
典型阻塞链：行锁 → 意向锁 → 表锁申请失败
阻塞不是意向锁主动造成的，而是它暴露了底层行锁的存在，从而让表锁申请者“知难而退”。比如：
- 事务A执行
UPDATE user SET name='x' WHERE id=100→ 自动加IX+ 行X锁 - 事务B执行
LOCK TABLES user WRITE→ MySQL发现user表有IX→ 判断“肯定有行被锁” → 直接阻塞事务B - 此时
SHOW PROCESSLIST看到事务B状态是Waiting for table metadata lock，而非“waiting for table lock”
容易忽略的关键点：MDL锁才是真正的阻塞源头
生产中遇到的“表锁阻塞”，90%以上实际是元数据锁（MDL）在起作用，不是意向锁本身。比如ALTER TABLE需要MDL_EXCLUSIVE，而此时若有长事务正在执行SELECT ... FOR UPDATE，它持有的IX虽不直接冲突，但会阻止MDL_EXCLUSIVE获取——因为MDL机制会等待所有活跃事务释放其持有的意向锁（即等事务提交或回滚）。这才是最常被误认为“意向锁导致阻塞”的真实原因。
