外键约束检查发生在 INSERT/UPDATE/DELETE 的哪个时刻
MySQL 的外键检查不是在语句提交时才做，而是在每条 INSERT、UPDATE 或 DELETE 语句执行过程中实时触发的——只要涉及被外键约束的列或被引用的主表/唯一键表，就会立刻校验。
这意味着：
-
INSERT INTO child_table (parent_id) VALUES (123)会立即查parent_table是否存在id = 123 -
UPDATE child_table SET parent_id = 999 WHERE id = 5同样触发对parent_table的存在性检查 -
DELETE FROM parent_table WHERE id = 42会先扫描所有子表中是否有parent_id = 42的行（取决于ON DELETE策略）
注意：如果事务中有多条语句，检查是逐条发生的，不是等到 COMMIT 才统一校验。这也是为什么在事务里先删父记录、再插子记录会直接报错。
如何临时关闭外键检查来绕过校验
用 SET FOREIGN_KEY_CHECKS = 0 可以全局禁用当前会话的外键检查，但必须清楚后果——它不修复数据一致性，只跳过校验。
常见误用场景：
- 导入旧数据前没关，批量
INSERT报错；关了之后忘了开，后续写入产生脏数据 - 在存储过程中动态拼接 SQL 并执行，
FOREIGN_KEY_CHECKS状态容易丢失 -
mysqldump默认导出时带SET FOREIGN_KEY_CHECKS=0，但恢复时依赖这个开关生效，若用其他工具导入可能失效
安全做法是显式控制作用域：
SET FOREIGN_KEY_CHECKS = 0; INSERT INTO child_table ...; INSERT INTO parent_table ...; -- 顺序反了也没事 SET FOREIGN_KEY_CHECKS = 1;
别依赖连接池自动重置，不同客户端行为不一致。
ON DELETE 和 ON UPDATE 触发时机与限制
ON DELETE CASCADE 或 ON UPDATE SET NULL 这类动作，是在主表记录被真正删除或更新「之后」才触发子表操作，且整个过程在一个事务内原子执行。
关键限制：
- 不能跨引擎：父表和子表都必须是
InnoDB；MyISAM完全不支持外键 -
SET NULL要求对应列允许为NULL，否则建表失败 - 级联操作有深度限制，MySQL 不支持多层递归级联（比如 A→B→C，删 A 不会自动删 C）
- 触发级联时，子表上的外键列也会重新校验——例如
ON UPDATE CASCADE更新子表后，该值是否仍满足其他外键约束？会再检查一遍
典型错误：Cannot delete or update a parent row: a foreign key constraint fails，往往是因为子表有记录，但定义的是 ON DELETE RESTRICT（默认），而不是 CASCADE 或 SET NULL。
外键检查对性能和锁的影响
每次外键检查都会引发一次额外的索引查找——哪怕只是确认父表某值存在，也要走一遍 parent_table 的主键或唯一索引。
这带来两个实际影响：
- 高并发写入子表时，大量检查会争抢父表的主键索引上的共享锁（S 锁），导致阻塞，尤其当父表是热点（如用户表、配置表）时
-
DELETE FROM parent_table WHERE ...在有大量子记录时，需要先扫描子表判断是否允许删除，这个过程可能很慢，甚至触发全表扫描（如果子表外键列没建索引）
所以必须确保：所有外键列（子表中的 parent_id 等）都建了索引。否则不仅慢，还会在 ALTER TABLE 添加外键时直接失败，报错 ERROR 1822 (HY000): Failed to add the foreign key constraint. Missing index for constraint。
外键不是银弹，它保一致性，但不保性能。线上大表慎加，加之前先看索引、看查询模式、看是否真需要数据库层强约束。
