MySQL 外键约束为什么拖慢批量删除：索引、级联与锁范围核对

订单归档任务里，主表 orders 只删了几千行，事务却迟迟不提交，业务请求还开始出现锁等待。遇到这种现象，别先把 DELETE 改成更大的批次：外键检查会逐行确认子表引用，级联规则还可能把一次主表删除扩展成多张表的写操作。

先确认一次删除实际牵动了哪些表

假设订单关系是 orders(id) 对应 order_items(order_id)，还有一张 order_events(order_id)。先把外键关系查出来，不要凭表名猜：

SELECT TABLE_NAME, COLUMN_NAME,
       CONSTRAINT_NAME, REFERENCED_TABLE_NAME,
       REFERENCED_COLUMN_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE REFERENCED_TABLE_SCHEMA = DATABASE()
  AND REFERENCED_TABLE_NAME = 'orders';

这一步能回答两个关键问题：哪些子表会阻止父表删除，哪些子表会被级联清理。若约束是 RESTRICT 或默认行为，子表仍有引用时父表删除会失败；若是 CASCADE，删除范围则会沿着关系继续展开。

子表外键列必须先过索引检查

删除 orders.id 时，InnoDB 需要检查 order_items.order_id 是否存在引用。用下面的语句核对子表索引：

SHOW CREATE TABLE order_items\G
SHOW INDEX FROM order_items;

重点不是索引名字，而是索引的第一列是否就是 order_id。如果只有一个以 created_at 开头的复合索引，不能把它当成外键检查的等价替代。可以按真实约束补上：

ALTER TABLE order_items
  ADD INDEX idx_order_items_order_id (order_id);

线上执行前应单独评估元数据锁和磁盘空间。索引补好后，先在低峰用少量主键验证删除耗时；这里别急着把整个历史月份一次清掉。

级联删除要按子表写放大重新估算

如果约束定义为：

CONSTRAINT fk_items_order
  FOREIGN KEY (order_id) REFERENCES orders(id)
  ON DELETE CASCADE

删除 1000 个订单并不代表只写 1000 行。每个订单可能关联几十条明细和事件记录，undo、redo、binlog 以及二级索引维护都会按实际删除行数增长。级联链上还有其他子表时，锁和日志峰值更难从父表数量直接推断。

若业务需要保留审计记录，不要为了清理方便直接把所有关系都改成级联。可以先把订单标记为待清理，再按明确顺序删除明细、无须保留的事件，最后删除父表，并把每一批的起止主键写入任务日志。

用主键窗口把清理拆成可回退的批次

不要使用不断增大的 OFFSET。更稳定的方式是保存订单主键游标，先处理子表，再处理父表：

START TRANSACTION;

DELETE oi
FROM order_items AS oi
JOIN orders AS o ON o.id = oi.order_id
WHERE o.id > :last_id AND o.id  :last_id AND id 

每批大小要由单批耗时、锁等待和子表平均行数共同决定。先用 200～1000 个父表主键做基线，确认 ROW_COUNT() 与预期关系，再逐步调整。发生异常时回滚当前批次，只有提交成功后才推进 last_id。

四个信号一起验收删除结果

• 父子行数：删除前后分别统计目标订单、明细和事件数量，确认没有意外扩大范围。
• 锁等待：观察 performance_schema.data_lock_waits 和业务接口延迟。
• 约束错误：记录外键错误，不要用关闭约束检查来掩盖关系数据问题。
• 残留核对：对已提交批次查询孤儿明细和未处理父表，确认游标没有跳过区间。

如果删除速度提升但业务延迟变差，说明批次仍然过大或清理时间撞上在线写入。缩小主键窗口、避开高峰，通常比关闭外键检查更可控。

常见问题：外键删除的三个边界

子表外键没有索引，父表一定删不掉吗？

不一定，删除可能仍能完成，但引用检查成本可能很高。应以执行耗时、锁等待和真实数据量验证，不能把“能删”当成“适合线上批量删”。

把 FOREIGN_KEY_CHECKS 设为 0 能解决锁等待吗？

不应把它当作常规优化手段。它可能掩盖引用关系和数据完整性问题，批量清理应优先修正索引、缩小事务和明确删除顺序。

有级联删除时还要手动删子表吗？

取决于审计保留、删除顺序和批次控制要求。需要精确统计、分段提交或保留部分事件时，手动按关系顺序处理更容易验收。

把外键清理收敛成一条安全规则

先查约束，再查子表外键索引；先估算级联带来的实际行数，再按稳定主键分批提交；每批提交后核对行数、锁等待和残留关系。这样处理的重点不是让某条 DELETE 短暂跑得最快，而是让清理任务在失败、重跑和业务高峰下都能解释、能回退。