外键操作不直接导致死锁，但因隐式加锁和不可控锁顺序极易引发死锁：update时自动对子表匹配行加s锁，无索引则全表扫描并升级为大量行锁；级联操作扩大锁范围且锁序不透明，易形成abba死锁；外键列必须建最左前缀索引，否则锁失效，且索引、禁用级联、应用层拆分三者缺一不可。
外键操作本身不直接死锁，但会让死锁变得极容易发生——根本原因是它引入了**隐式加锁**和**不可控的锁顺序**，而这两点在高并发下几乎必然撞上。
外键 UPDATE 时为什么悄悄加 S 锁？
执行 UPDATE parent_table SET id = ? WHERE ... 时，InnoDB 必须校验子表里有没有引用这行的记录。它会自动对子表中所有匹配 parent_id = ? 的行加 LOCK_S（共享锁），这个动作你代码里根本没写，也看不到。
- 如果子表
parent_id没索引，InnoDB 只能全表扫描 → 实际上给子表几乎所有行都加了 S 锁 - 此时另一个事务正执行
INSERT INTO child_table (parent_id, ...) VALUES (?, ...)，需要获取插入意向锁（Insert Intention Lock） - S 锁和插入意向锁冲突 → 等待链形成，再交叉一下就死锁
ON DELETE CASCADE / ON UPDATE CASCADE 是怎么放大风险的？
级联操作不是“原子省事”，而是把锁范围从一行扩展到 N 行，且锁顺序完全由 InnoDB 内部决定，应用层无法干预。
-
DELETE FROM parent_table WHERE id = 123触发级联删子表 → InnoDB 扫描子表、逐行加 X 锁、再删 → 锁持有时间长、范围大 - 若子表数据量大，这条语句可能卡住几秒，期间阻塞所有其他访问该父记录的事务
- 更危险的是：事务 A 先删父表、再更新子表；事务 B 先更新子表、再删父表 → 经典 ABBA 死锁闭环
为什么 SHOW ENGINE INNODB STATUS 里找不到外键相关线索？
外键锁是“隐身”的——日志里不会出现 FOREIGN KEY 字样，只显示锁落在哪张表、哪个索引、哪几行。
- 看到
lock_mode X locks rec but not gap on table `db`.`child_table`，但 SQL 里根本没操作child_table→ 外键隐式锁 - 等待链中两个事务分别持有
parent_table和child_table的 X 锁，互相等待 → 典型外键引发的 ABBA - 锁信息里 index 名是
GEN_CLUST_INDEX或 page no 范围极大 → 暗示子表全表扫描，外键列缺索引
外键列索引为什么必须是最左前缀？
InnoDB 不会复用父表索引，也不认组合索引里靠后的列——它只认外键列作为索引最左一列的结构。
- ✅ 有效：
CREATE INDEX idx_fk_user_id ON orders(user_id)或CREATE INDEX idx_fk_user_status ON orders(user_id, status) - ❌ 无效：
CREATE INDEX idx_wrong ON orders(status, user_id)——user_id不在最左，InnoDB 加锁时仍会全表扫 - ⚠️ 注意：即使子表主键是
(user_id, order_id)，只要外键只引用user_id，就必须单独建以user_id开头的索引
真正麻烦的不是加索引或拆逻辑，而是所有环节必须同步生效：索引没建好，拆了级联也没用；禁用了 CASCADE，但应用层还留着 ORM 的 on_update=models.CASCADE 配置，照样触发隐式锁。漏掉任何一环，死锁照常发生。
