MySQL 外键约束为什么让删除变慢：级联动作、索引覆盖与锁范围

线上清理一批过期订单时，删除 order_header 的主键记录突然比平时慢很多，慢的并不一定是这条主表记录本身，而可能是 InnoDB 为外键约束检查 order_item.order_id，又执行了级联动作并等待子表上的锁。排查这类问题，先看外键动作和子表索引，再看事务是否把锁持有得太久。

外键不会凭空让删除变慢；真正需要核对的是子表外键列是否有合适索引、删除动作是否级联，以及级联链路上是否存在锁等待。

一条删除语句实际经过了哪些表

假设订单主表和明细表这样定义：

CREATE TABLE order_header (
  id BIGINT PRIMARY KEY,
  status VARCHAR(20) NOT NULL
) ENGINE=InnoDB;

CREATE TABLE order_item (
  id BIGINT PRIMARY KEY,
  order_id BIGINT NOT NULL,
  sku_id BIGINT NOT NULL,
  CONSTRAINT fk_item_order
    FOREIGN KEY (order_id) REFERENCES order_header(id)
    ON DELETE CASCADE,
  KEY idx_item_order_id (order_id)
) ENGINE=InnoDB;

执行 DELETE FROM order_header WHERE id = 9001 时，InnoDB 先定位父表记录，再沿着 fk_item_order 找到对应的明细。若动作是 CASCADE，明细也会被删除；若是默认的 NO ACTION，仍有子记录时则会拒绝父记录删除。

先确认外键动作，不要只盯着删除耗时

生产环境里常见的误判是：看到删除慢，就先给父表加索引。父表主键通常已经能快速定位，真正决定后续成本的是子表外键动作。先执行：

SHOW CREATE TABLE order_item\G

重点看三处：约束是否确实引用了预期父表，ON DELETE 是 CASCADE、RESTRICT 还是默认动作，以及 order_id 是否出现在子表索引的第一列。不要把“有一个包含 order_id 的联合索引”直接等同于“能高效按 order_id 查找”，例如 KEY (sku_id, order_id) 对这个外键访问就不是同一个效果。

如果删除只是业务上的状态淘汰，通常更稳妥的是更新 status，把物理删除放到经过限量和监控的清理任务里。级联适合关系明确、子记录数量可控的场景；一条父记录可能挂几十万条明细时，级联语义本身就会放大事务。

子表索引如何改变检查成本和锁范围

外键列索引的价值不只是速度。它让 InnoDB 能按 order_id 定位相关子记录，减少无关记录参与检查；当索引缺失或列顺序不合适时，扫描和锁等待更容易被放大。可以对明细查询做一个最小核对：

EXPLAIN SELECT id
FROM order_item
WHERE order_id = 9001;

在真实数据量和真实索引下观察访问类型、可能使用的索引和预计行数；本例把外键值记成 order_id=9001，方便把执行计划和图中的定位点对应起来。不要把 EXPLAIN 的估算行数当成锁数量，它只是优化器估算；最终还要结合当前事务和锁等待信息判断。

遇到删除卡住时，按锁等待而不是按猜测处理

如果语句长时间处于等待，不要连续重试同一条删除。先查当前事务和锁等待，找到持锁会话后确认它在做什么：未提交的明细更新、长时间报表查询，还是另一条清理任务。杀掉会话前要确认业务影响，尤其是订单写入和结算事务。

处理大批量过期订单时，可以按主键范围分批，每批完成后提交，并记录已完成的最大 order_header.id。这样即使中途失败，也能从明确边界恢复，不会把整个历史清理任务放进一个巨大事务。

三个容易踩坑的边界

把 CASCADE 当成异步删除

级联动作属于当前语句和事务的一部分，不是后台队列。子表越大，提交前需要处理的工作越多，回滚成本也越高。

只给父表加索引

父表主键能解决父记录定位，却不能替子表外键列提供反向查找。应从子表的约束和索引定义一起检查。

为了绕过慢删除临时关闭外键检查

这会改变完整性保护边界，不能当作常规性能开关。若确实需要迁移或修复，应先设计可回滚的窗口、校验孤儿记录，再按变更流程执行。

把结论落到一次可复核的变更上

这类问题的最小闭环是：保存 SHOW CREATE TABLE 结果，确认子表外键列的索引首列；用 EXPLAIN 验证按外键列查找的访问路径；在复现或线上窗口记录锁等待；最后用少量主键范围验证删除耗时、受影响行数和事务提交时间。只要把“级联动作、子表访问、锁等待”分开看，通常就能判断慢在约束检查、实际删除，还是被另一事务挡住。

相关问题

外键列没有显式索引会怎样？

InnoDB 会要求引用列具备合适索引；建表时可能自动创建，之后也可能因其他可用索引而被移除。最终以 SHOW CREATE TABLE 和索引定义为准。

RESTRICT 和 NO ACTION 有什么区别？

在 InnoDB 的常见使用中，两者都阻止仍有子记录的父表删除；默认动作是 NO ACTION。需要向读者或运维明确表达拒绝语义时，显式命名约束动作更容易复核。