外键约束检查发生在每行变更落地前的即时阶段。insert时先查父表匹配记录，update时校验新旧值，delete父记录前扫描子表引用，且检查与加锁原子绑定。
外键约束检查发生在 INSERT/UPDATE/DELETE 的哪个阶段
MySQL 在执行 DML 时，外键检查不是在语句末尾统一校验，而是在每行变更「落地前」即时触发。对 INSERT，先查父表是否存在匹配的 parent_id；对 UPDATE 修改外键列时，既查新值（是否在父表存在），也查旧值（若级联删除或设为 NULL，需确认旧记录仍可被引用）；DELETE 父记录前，必须扫描子表验证是否有活跃引用——这步会触发表级或范围锁。
关键点：检查与加锁是原子绑定的。比如 INSERT INTO child (pid) VALUES (123)，InnoDB 会先对父表中 id = 123 的行加 S（共享）锁，再插入子行；若父行不存在或已被其他事务独占（X 锁），直接报错 Cannot add or update a child row: a foreign key constraint fails。
父子表锁定顺序与死锁风险怎么规避
InnoDB 强制按「父表 → 子表」顺序加锁。但应用层若反向操作（比如先更新子表再删父表），或跨事务混合操作，极易引发死锁。典型错误模式：
- 事务 A：
DELETE FROM parent WHERE id = 100→ 尝试锁父行 + 扫描子表 → 需要子表上对应范围的LOCK_S - 事务 B：
INSERT INTO child (pid) VALUES (100)→ 先锁父表id = 100行（S）→ 再插子行
此时若事务 A 已持有子表锁、事务 B 已持有父表锁，就卡住。规避方法只有两个：
- 所有涉及父子表的操作，严格按「父 → 子」顺序执行（如删父前确保子已清空）
- 把关联操作包进单个事务，避免中间状态暴露给其他并发事务
- 对高频引用场景，考虑关闭外键（
FOREIGN_KEY_CHECKS = 0），但必须由应用层兜底校验
ON DELETE CASCADE 实际触发时机与锁行为
ON DELETE CASCADE 不是延迟执行，而是在父行 DELETE 语句执行过程中同步触发子行删除。这意味着：父行加 X 锁后，InnoDB 立即根据外键索引定位子行，逐条加 X 锁并删除——整个过程不可分割。
注意三点：
- 子表必须在外键列上有索引，否则会触发全表扫描加锁，性能雪崩
- 如果子表数据量大，
DELETE FROM parent可能长时间持锁，阻塞其他读写 - 级联操作不支持部分回滚：父行删了一半失败，子行已删的部分不会自动回滚（事务整体回滚才生效）
示例：执行 DELETE FROM orders WHERE id = 12345，若 order_items.order_id 是外键且有 CASCADE，则 InnoDB 会走 order_items 上的 order_id 索引，对匹配的所有子行加 X 锁并标记删除。
如何快速定位外键校验失败的具体原因
报错信息 foreign key constraint fails 默认不告诉你哪一列、哪个值出问题。要定位，得结合三方面查：
- 用
SHOW CREATE TABLE child_table确认外键定义，找到CONSTRAINT名和引用列 - 查失败语句中的外键值（如
INSERT ... VALUES (999)），然后手动执行SELECT id FROM parent_table WHERE id = 999，看是否为空或被锁 - 开启
innodb_status_output并查SHOW ENGINE INNODB STATUS，在LATEST FOREIGN KEY ERROR段能看到最近一次失败的完整 SQL 和表名
最常被忽略的是隔离级别影响：在 REPEATABLE READ 下，若父行被其他事务修改但未提交，当前事务可能读不到最新状态，导致误判「父行不存在」而报错——这时需要确认父表是否有未提交事务卡住。
