外键验证必须加锁以保障一致性，InnoDB对父表被引用行加S锁（SELECT…LOCK IN SHARE MODE），子表无索引时会升级为全表扫描并锁表，级联操作逐行加锁导致性能恶化。
外键验证必须加锁，否则会破坏一致性
MySQL 在执行涉及外键的操作（比如 INSERT、UPDATE、DELETE）时，并不是“顺便查一下父表有没有对应记录”那么简单。它必须确保这个检查过程本身是原子且隔离的——也就是说，不能在你查完父表存在某 ID 后，另一事务立刻删掉它，然后你的插入就写入了“孤儿数据”。所以 InnoDB 会对父表中被引用的那行（或索引项）加 SELECT ... LOCK IN SHARE MODE 类型的共享锁，子表操作完成前不释放。
- 例如：
INSERT INTO orders (customer_id) VALUES (123)会尝试对customers表中id = 123的记录加 S 锁；如果该行正被其他事务用 X 锁修改，当前插入就会等待 - 又如：
DELETE FROM customers WHERE id = 123会先检查所有子表（如orders）是否还有引用，这个检查过程要扫描子表外键索引，同时为防止并发插入新引用，还会在子表外键索引上加间隙锁（gap lock） - 级联删除更重：每删一条子记录，都要重新校验父表主键是否存在（虽然实际是冗余检查），并触发新一轮外键验证锁
没索引的外键列会让锁范围扩大到全表
外键列如果没有索引，InnoDB 就无法快速定位子表中哪些行引用了某个父表值。于是它只能走全表扫描来确认——而为了保证扫描结果不被并发修改干扰，InnoDB 会在整个子表上加意向锁（IX），再配合行锁或间隙锁，实际效果接近“锁住子表大部分活跃区域”。这就是为什么你看到 DELETE FROM parent WHERE id = X 突然卡住，背后可能是子表没索引导致的隐式全表扫描+锁升级。
- 常见错误现象：
SHOW ENGINE INNODB STATUS显示大量waiting for table metadata lock或长时间lock wait timeout，但 SQL 看起来很轻量 - 验证方式：对子表外键列执行
SHOW INDEX FROM child_table，确认是否有对应索引；没有就立刻补上：ALTER TABLE child_table ADD INDEX idx_fk_parent_id (parent_id) - 注意：复合外键必须按顺序建联合索引，只给单列建索引无效
级联操作不批量，逐行加锁是性能杀手
ON DELETE CASCADE 听起来方便，但 InnoDB 实现上是“找到一条子记录 → 删除它 → 触发下一轮外键检查 → 再找下一条”，而不是一次性定位全部子记录再批量删。这意味着：
- 每条子记录都经历一次独立的锁获取/释放周期，锁竞争概率指数上升
- 无法利用批量删除的优化路径（如
DELETE ... LIMIT分片），容易超时 - 若子表有二级索引，每删一行还要更新所有相关索引页，放大 I/O 和锁持有时间
真正可控的删除逻辑，永远是业务层分步做
别指望数据库替你扛住大数据量下的外键压力。最稳妥的做法是把“删父表”拆成三步：先 SELECT id FROM child_table WHERE parent_id = X 拿到子记录 ID 列表（加 FOR UPDATE 防并发），再用 DELETE FROM child_table WHERE id IN (...) 批量删（注意 IN 参数上限），最后删父表。这样你能控制锁粒度、分批提交、加监控、失败可重试——而原生级联做不到任何一项。
外键不是开关，是契约；它的开销不在语法里，而在每次验证时对锁和索引的真实调用。忽略索引、滥用级联、把外键当业务逻辑代理，才是多数人踩坑的起点。
