外键校验逐行发生，无法批量合并，每行插入均触发独立存在性检查、加锁与释放，高并发下IO和锁竞争指数级放大；必须为外键字段创建高效索引，慎用ON DELETE CASCADE，必要时将校验移至应用层。
外键校验是逐行发生的，无法合并
哪怕你用 INSERT INTO t VALUES (),(),()... 一次插入 1000 行，MySQL 也不会把这 1000 个外键值去重后批量查一次父表。它会为每一行单独执行一次存在性检查：查索引（如果有）、加锁、返回结果、释放锁。这个过程在父表较大或并发高时，IO 和锁竞争会被指数级放大。
常见错误现象：SHOW PROCESSLIST 中大量线程卡在 Updating 或 Waiting for table metadata lock；slow_log 里出现大量看似简单的 INSERT 却耗时数秒。
- 复合外键字段未建对应复合索引 → 单列索引无效，照样全表扫描
- 父表主键无索引（极少见但可能）→ 子表外键检查直接扫父表全表
- 使用
LOAD DATA INFILE导入 → 同样触发逐行校验，不因语法“批量”而跳过
外键引发的锁行为比想象中更重
INSERT 子表记录时，MySQL 对父表加共享锁（S 锁）验证存在性；DELETE 或 UPDATE 父表主键时，则可能对子表加意向排他锁（IX）甚至全表扫描反查依赖——这不是“慢查询”，是阻塞源。
容易踩的坑：以为只是多几次查询，实际是锁等待链。比如一个 DELETE 父表记录的操作，可能让后续几十个并发 INSERT 子表的事务全部排队等锁，innodb_lock_wait_timeout 超时后报错 ERROR 1205 (40001): Deadlock found。
- 外键字段没索引 → 每次校验都触发父表全表扫描 + 全表 S 锁
- ON DELETE CASCADE → 一个 DELETE 可能触发 N 层递归锁，锁持有时间远超预期
- 事务隔离级别为
REPEATABLE READ（默认）→ 锁范围更大，加剧冲突
临时禁用 FOREIGN_KEY_CHECKS 不等于“解决性能问题”
SET FOREIGN_KEY_CHECKS = 0 确实能让导入快几倍，但它只是跳过校验，不消除外键本身的结构负担：InnoDB 仍要维护外键元数据、可能隐式建索引、且 SET FOREIGN_KEY_CHECKS = 1 时会强制做全量验证。
最危险的是数据一致性风险：一旦导入脏数据（如子表 customer_id 指向不存在的父表 id），再开启检查会直接报错 ERROR 1822 (HY000): Failed to add the foreign key constraint，表被锁死，必须手动清理非法行才能恢复。
- 仅限离线、单次、可控场景（如 ETL 初始化、测试环境灌库）
- 开启前必须确保数据已通过应用层或脚本校验干净
- 操作后务必立即执行
SET FOREIGN_KEY_CHECKS = 1，否则后续所有写操作都不受约束
真正有效的优化不是“关开关”，而是控制校验成本
外键本身不是坏东西，坏的是没索引、乱级联、盲目信任默认行为。性能瓶颈往往出在外键字段缺少高效索引，或业务根本不需要实时强一致。
关键点在于：外键字段是否作为查询条件高频出现？如果是，那索引收益远大于校验开销；如果只是“以防万一”，又面临高并发写入，那就得权衡——把校验移到应用层或异步任务里，比硬扛数据库锁更实际。
- 确认外键列已有独立索引，或作为复合索引的最左前缀
- 用
EXPLAIN验证SELECT ... FROM parent WHERE id = ?是否走索引 - 慎用
ON DELETE CASCADE，改用应用层分批删除 + 事务控制 - 高吞吐写入表可考虑移除外键，靠应用逻辑+定时校验兜底
max_allowed_packet 或换 LOAD DATA，却忘了先看 SHOW CREATE TABLE 里外键字段有没有索引——这才是最常被跳过的一步。 
