外键UPDATE引发死锁的根本原因是外键校验强制跨表加S锁，且子表parent_id缺失索引导致全表扫描与多行锁定；解决需三步：紧急建索引止血、评估后在线拆除外键、应用层通过显式校验+异步稽核兜底保障一致性。
MySQL 5.7 中外键检查引发的“锁死”（实为死锁或长等待），根本不是锁没释放，而是外键校验强制跨表加锁 + 子表缺失索引导致锁范围爆炸。解决路径很明确：先止血（建索引），再拆弹（评估并拆除外键），最后兜底（应用层一致性保障）。
为什么UPDATE子表会卡住父表甚至整张子表
InnoDB 执行 UPDATE child_table SET status = 'x' WHERE id = 123 时，只要该表有外键指向父表，就会触发外键检查——它必须确认 child_table.parent_id 对应的父记录还存在。这个检查分两步：SELECT ... FROM parent_table WHERE id = ? LOCK IN SHARE MODE（父表 S 锁），再对当前子表行加 X 锁。但若 child_table.parent_id 列没有索引，InnoDB 就无法快速定位哪些子行引用了某个父 ID，只能全表扫描；扫描过程中会对**所有被检查的行逐个加锁**（哪怕只改一行），结果就是：一条 UPDATE 锁住几百上千行，其他事务一碰就等，看起来像“锁死”。
- 现象：慢查询日志里
UPDATE耗时突增、SHOW PROCESSLIST显示大量Updating或Waiting for table metadata lock - 验证方法：执行
EXPLAIN SELECT * FROM child_table WHERE parent_id = 100，如果type是ALL，说明没走索引 - 紧急修复：立即执行
ALTER TABLE child_table ADD INDEX idx_parent_id (parent_id)（注意是单列索引，或以parent_id为最左前缀的复合索引）
SHOW ENGINE INNODB STATUS 里看到 FOREIGN KEY 相关锁等待怎么办
这是外键死锁的铁证。在输出的 LATEST DETECTED DEADLOCK 段落里，你会看到类似 *** (1) TRANSACTION: ... FOREIGN KEY ... 和锁等待链涉及两张表。这说明两个事务正在交叉争夺父表某行和子表某些行的锁。
- 典型死锁环：事务 A 持有子表行 X 的 X 锁，正等父表行 P 的 S 锁；事务 B 持有父表行 P 的 X 锁（比如在
DELETE FROM parent_table WHERE id = P），正等子表所有parent_id = P行的 X 锁 - 关键线索：看锁等待中是否出现
lock_mode S locks rec but not gap（父表 S 锁）和lock_mode X locks rec but not gap（子表 X 锁）同时存在 - 临时缓解：禁止
ON DELETE CASCADE和ON UPDATE CASCADE，它们会让一次 DML 触发多次隐式外键检查，锁链更长、更不可控
在线安全拆除外键的三步操作（MySQL 5.7 支持）
MySQL 5.7 默认支持 ALGORITHM=INPLACE, LOCK=NONE 删除外键，但前提是表结构允许且没有长事务阻塞。不能直接 ALTER TABLE ... DROP FOREIGN KEY 了事，否则可能留下孤儿数据。
- 第一步：确认外键是否真被业务使用——搜代码里有没有
ON DELETE CASCADE、ORM 的on_delete配置、存储过程里的INSERT INTO child逻辑 - 第二步：手动校验数据一致性——运行
SELECT COUNT(*) FROM child_table c LEFT JOIN parent_table p ON c.parent_id = p.id WHERE p.id IS NULL，结果必须为 0 - 第三步：执行在线删除——
ALTER TABLE child_table DROP FOREIGN KEY fk_name ALGORITHM=INPLACE, LOCK=NONE；若报错LOCK=NONE is not supported，降级为LOCK=SHARED（允许读，阻塞写，窗口极短）
拆除后如何防止应用写入脏数据
外键物理移除后，约束能力不会自动转移到应用层。靠文档、靠约定、靠“应该没人绕过 ORM”都是高危假设。必须有可验证、可告警、可修复的机制。
- 写入前显式校验：在同一个事务里，先
SELECT id FROM parent_table WHERE id = ? FOR UPDATE，再执行子表 INSERT/UPDATE；注意FOR UPDATE会锁父表行，别滥用 - 异步稽核兜底：每天跑一次
SELECT c.* FROM child_table c LEFT JOIN parent_table p ON c.parent_id = p.id WHERE p.id IS NULL LIMIT 100，发现就告警，严重时自动归档或清理 - ORM 层加固：Django 设置
on_delete=models.PROTECT，Laravel Eloquent 用->references('id')->on('parent_table')配合事务，但要清楚——这些只拦住 ORM 调用，DBA 直连或脚本 SQL 仍能绕过
真正难的不是建索引或删外键，而是让团队接受「一致性不再由数据库保证，而由监控+流程+代码共同承担」。一旦上线，就要盯紧稽核任务的失败率和告警响应速度——那才是外键拆除后最真实的水位线。
