MySQL 外键删除变慢怎么排查：锁等待、索引缺失与级联边界

线上清理订单时，父表一条删除语句从几十毫秒拖到几秒，最容易误判成“外键本身很慢”。更稳妥的做法是先把现场拆成三条线：当前事务有没有等锁，子表外键列能不能快速定位，级联动作是不是把一次删除放大成了整批写入。

先还原现场：慢的是等待还是扫描

假设订单主表是 orders，明细表是 order_items，明细表通过 order_id 引用主表。先不要直接执行第二次删除，保留一次正在运行的会话，在另一个连接查看 InnoDB 事务：

SELECT trx_id, trx_state, trx_started, trx_wait_started,
       trx_mysql_thread_id, trx_query
FROM information_schema.innodb_trx
ORDER BY trx_wait_started;

如果 trx_state 是 LOCK WAIT，优先沿阻塞链查占用者；如果没有等待事务，再转向执行计划和子表索引。这个分叉很重要：给一个本来在等业务事务的删除语句加索引，通常解决不了眼前的卡顿。

第二条线：确认子表外键列真的有索引

外键约束写在 order_items.order_id 上，不等于你已经有了理想索引。检查表结构时要看索引列顺序，而不是只看约束名字：

SHOW CREATE TABLE order_items\G
SHOW INDEX FROM order_items;

如果明细表只有 (status, created_at) 这类联合索引，删除父表时仍可能需要在子表中扫描大量记录。一个常见的修复是补建以 order_id 为首列的索引：

ALTER TABLE order_items
  ADD INDEX idx_order_items_order_id (order_id);

上线前先确认已有相同前缀的索引，避免重复建设；还要估算索引创建期间的变更压力。索引完成后，用测试订单做一条小范围删除，核对扫描范围和锁等待是否消失。

第三条线：把级联删除当成一组写操作

ON DELETE CASCADE 的含义不是“只删一行”。父表删除会触发子表匹配行的删除，子表还有下游引用时，写入链路会继续扩展。订单历史、退款记录这类数据通常不适合无条件级联，先查约束定义：

SELECT TABLE_NAME, CONSTRAINT_NAME, DELETE_RULE
FROM information_schema.REFERENTIAL_CONSTRAINTS
WHERE CONSTRAINT_SCHEMA = DATABASE()
  AND REFERENCED_TABLE_NAME = 'orders';

如果结果显示多个下游表都是 CASCADE，一次父表删除就可能带来多表锁竞争。这里别急着把级联改成 RESTRICT：先确认应用是否依赖级联语义，再设计归档、软删除或按批次清理方案。

修复顺序：先解除等待，再处理结构

1. 确认阻塞者。 找到持有未提交事务的连接，先判断它是否仍在执行合法业务；不要直接终止未知连接。
2. 补齐子表索引。 让外键列成为可检索路径，并在低风险窗口验证索引创建影响。
3. 缩小单次删除。 用主键范围或时间窗口分批执行，批次结束后提交并记录删除行数。
4. 复核级联策略。 对订单、账务、审计等需要留痕的数据，优先考虑归档与软删除。

DELETE FROM orders
WHERE id >= 120000 AND id 

示例中的批次大小只是起点，实际值要根据锁等待、日志增长和复制延迟调整。不要把大事务拆成多条语句却一直不提交，那只是把一次长等待改成另一种长等待。

复查结果：三个信号都要对上

修复后再次执行同类删除，至少记录三个结果：等待事务是否回到空集、每批实际影响行数是否符合预期、下游表是否出现意外删除。若使用 EXPLAIN 检查关联查询，只把它作为访问路径证据，不要用一份静态计划替代真实事务现场。

如果等待仍然存在，回到阻塞链；如果等待消失但单批仍慢，继续查看批次范围、磁盘写入和级联下游。根因确认要能解释“为什么这次慢、为什么这个改动有效”，而不是只留下一个更大的超时阈值。

常见问题

父表有主键，为什么删除还会慢？

父表定位本身可能很快，但外键检查需要访问子表。子表外键列缺少合适索引时，扫描和锁影响会落在删除链路上。

看到 LOCK WAIT 就应该终止阻塞连接吗？

不应该直接终止。先确认阻塞连接属于哪个业务、事务是否还能提交，以及终止后是否会触发更大的回滚。

级联删除一定比应用逐表删除好吗？

不一定。级联能保持约束一致性，但也会隐藏写入范围；需要审计、归档或分批控制时，显式流程往往更容易观测。

总结

MySQL 外键删除变慢，按“锁等待—子表索引—级联范围”的顺序排查最省时间。先用事务现场确认等待，再用表结构确认访问路径，最后评估级联写入和批次边界，修复后用行数、等待和下游变化做闭环验收。