外键约束触发的死锁表现为两个事务交叉操作父表和子表，因外键列无有效索引导致全表扫描加锁，形成循环等待；典型特征是SHOW ENGINE INNODB STATUS中出现父表S锁与子表X锁互相等待，且锁对象集中于外键索引和主键索引。
外键约束触发的死锁长什么样
外键导致的 Deadlock found when trying to get lock 通常不是因为业务 SQL 写错了顺序，而是 MySQL 在维护外键一致性时自动加锁引发的隐式冲突。典型现象是：两个事务同时插入/更新主表和从表，且外键列无索引，InnoDB 被迫扫描并锁住大量行，最终在不同顺序下形成循环等待。
为什么外键列没索引会放大死锁风险
MySQL 要求外键列必须有索引（否则建表失败），但很多人忽略了「索引是否被真正用上」。如果外键列上只有复合索引且顺序靠后（如 INDEX (a, b, foreign_id)），或用了前缀索引、函数索引，InnoDB 就无法高效定位从表记录，转而执行全扫描+全表加锁。这种“锁扩大”会让本该只锁 1 行的操作变成锁几十甚至上百行，极大提高与其他事务交叉的概率。
- 检查方式：
SHOW CREATE TABLE child_table看外键列是否为独立索引或复合索引的最左前缀 - 错误示例：
FOREIGN KEY (order_id) REFERENCES orders(id)，但order_id只在INDEX (status, order_id)中——这不算有效索引 - 修复命令：
ALTER TABLE child_table ADD INDEX idx_order_id (order_id)
INSERT/UPDATE 外键字段时的锁行为差异
外键检查本身不直接加锁，但它会触发对父表的 SELECT ... LOCK IN SHARE MODE（级联检查）或对从表的加锁（级联更新/删除）。关键区别在于：
-
INSERT INTO child (order_id, ...)：需确认order_id在父表存在 → 对父表主键加 S 锁（共享锁），不阻塞读，但会与父表上的 X 锁冲突 -
UPDATE child SET order_id = ? WHERE id = ?：先释放旧外键关联的锁，再获取新外键的 S 锁 → 若两个事务交叉更新，可能先各自持有旧值锁，再争抢对方的新值锁 -
ON UPDATE CASCADE：更新父表主键时，会批量锁定所有从表匹配行 → 高并发下极易因锁顺序不一致死锁
线上已发死锁，怎么快速定位是不是外键惹的祸
别猜，直接看 SHOW ENGINE INNODB STATUS\G 输出里的 LATEST DETECTED DEADLOCK 段。重点找这几处：
- 事务持有的锁是否集中在父表主键（
index PRIMARY of table `db`.`parent`）和从表外键列（index idx_foreign of table `db`.`child`） - 日志中是否有类似
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS ... index PRIMARY ... lock_mode S—— S 锁等待说明是外键一致性检查卡住了 - 对比两个事务的 SQL：是否一个在更新父表主键，另一个在插入/更新从表外键字段？
外键相关死锁最难缠的地方在于它藏得深——你查业务 SQL 看不出问题，但只要父表主键被改、或从表外键值批量变更，就可能突然爆发。务必把外键列索引当成上线 checklist 的硬性项，而不是“有就行”的摆设。
