外键列无索引会导致性能瓶颈和死锁。必须为外键列手动创建独立单列索引或以该列为最左前缀的复合索引，字段类型需与父表主键严格一致；ON UPDATE CASCADE 会放大锁范围并引发ABBA死锁；应用层两步更新须用FOR UPDATE加锁并包裹在事务中；RR隔离级别下Next-Key Lock易阻塞，并发高时可临时降为RC；ORM框架的级联配置需彻底清理。
外键列没索引是性能瓶颈的根源
MySQL InnoDB 不会自动为外键列创建高效索引，只在它是 PRIMARY KEY 或 UNIQUE KEY 时才附带索引。如果 child_table.parent_id 是普通外键列且无索引，每次 UPDATE parent 都会触发子表全表扫描 + 表级意向锁，不是慢，是直接卡死。
必须手动建索引，且不能依赖联合索引前缀——InnoDB 只认「独立单列索引」或「以该外键列为最左前缀的复合索引」：
ALTER TABLE child_table ADD INDEX idx_parent_id (parent_id);- 若已有复合索引
(status, parent_id)，它对WHERE parent_id = ?无效 - 索引字段类型需与父表主键严格一致（如都是
BIGINT UNSIGNED），否则隐式转换导致索引失效
ON UPDATE CASCADE 本身就会放大锁范围
启用 ON UPDATE CASCADE 后，UPDATE parent SET id = ? 不再只是改一行，而是隐式执行子表批量更新，且这个过程不受事务语句顺序控制——锁顺序由 InnoDB 内部扫描路径决定，极易形成 ABBA 死锁环。
即使加了索引，也挡不住这种隐式行为：
- 事务 A：先
UPDATE parent→ 锁住子表部分行 → 再显式UPDATE child→ 等待其他锁 - 事务 B：先
UPDATE child→ 持有子表行锁 → 再UPDATE parent→ 触发级联 → 尝试重锁同一行 →Deadlock found when trying to get lock - 级联操作无法被
EXPLAIN分析，你看到的只是最终报错，不是执行计划
应用层两步更新必须带 FOR UPDATE 和事务包裹
把级联逻辑移到应用层后，常见错误是漏掉一致性保障。单纯 SELECT id FROM child_table WHERE parent_id = ? 再 UPDATE，可能读到旧快照，导致部分子记录漏更新。
正确做法是用显式锁+原子事务：
- 整个操作必须在同一个
BEGIN/COMMIT内完成 -
SELECT id FROM child_table WHERE parent_id = ? FOR UPDATE;—— 这会加 X 锁，阻塞其他事务修改这些行 - 避免
SELECT ... JOIN parent_table，否则会额外锁父表，扩大锁范围 - 批量
UPDATE child_table SET parent_id = ? WHERE id IN (...)的IN列表长度建议 ≤ 1000，超长易触发优化器放弃索引
隔离级别影响锁粒度，RR 下 Next-Key Lock 更危险
MySQL 默认的 REPEATABLE READ 隔离级别会让 SELECT ... FOR UPDATE 加 Next-Key Lock（记录锁 + 间隙锁），不仅锁住匹配行，还锁住“不存在但可能插入的位置”。这在并发插入场景下极易意外阻塞。
若业务允许读已提交数据，可临时降级：
-
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;之后再BEGIN - 此时
SELECT ... FOR UPDATE只加记录锁，不锁间隙，减少冲突面 - 注意：此设置仅对当前事务生效，不影响其他连接
真正容易被忽略的是 ORM 层的残留配置——比如 Django 的 on_update=models.CASCADE 或 Rails 的 dependent: :update，它们会在生成 SQL 时悄悄补上级联逻辑，哪怕数据库层已禁用外键。必须全局 grep 清理。
