外键检查在insert/update/delete时触发额外锁和全表扫描：若外键字段无索引，mysql需对父表全表扫描验证参照完整性，insert持s锁、delete/update主键可能加x锁，高并发下易引发阻塞与死锁；批量操作仍逐行校验，无法合并，load data infile亦受限制，仅set foreign_key_checks=0可跳过但须确保数据干净且仅限离线场景。
外键检查在INSERT/UPDATE/DELETE时触发额外锁和全表扫描
每次写操作都要校验参照完整性，而校验过程本身就有开销。比如向子表orders插入一条记录，MySQL必须确认customer_id在customers表中存在——若该字段没索引，就会对customers做全表扫描；删除父表某行时，还要反查所有子表依赖，同样可能扫全表。
更关键的是锁行为：INSERT会持共享锁查父表，DELETE或UPDATE主键则可能加排他锁，高并发下极易引发锁等待甚至死锁。这不是“慢”，是阻塞。
- 外键字段没索引 → 必然全表扫描，无论父子表大小
- 复合外键未建对应复合索引 → 单列索引无效，照样扫表
-
ON DELETE CASCADE触发连锁删除 → 一个DELETE可能变成N次递归操作，锁持有时间指数级增长
批量INSERT时外键检查无法合并，每行都单独校验
哪怕你用INSERT INTO t VALUES (),(),()...一次插1000行，MySQL仍会对每一行的外键字段单独做存在性检查。它不会把这1000个customer_id去重后批量查一次父表，而是逐个查、逐个锁、逐个放。
这意味着：1000行 × 每次查父表（可能全表扫） × 每次加锁 → IO和CPU双重浪费。尤其当父表大、子表并发高时，这个放大效应非常致命。
- 不能靠“批量语法”绕过外键开销，语法只减少网络和解析成本，不跳过约束检查
-
LOAD DATA INFILE同样受外键约束限制，除非先SET FOREIGN_KEY_CHECKS = 0 - 唯一能避免逐行校验的方式，是关掉检查，但必须确保数据本身干净
为什么临时禁用FOREIGN_KEY_CHECKS不是万能解药
SET FOREIGN_KEY_CHECKS = 0确实能让大批量导入快几倍，但它只是跳过校验，并不消除外键本身的结构负担。表定义里还挂着外键，InnoDB依然要维护外键元数据、生成隐式索引（如果缺失）、并在后续SET FOREIGN_KEY_CHECKS = 1时做全量验证。
更危险的是：一旦导入脏数据（比如orders.customer_id指向不存在的customers.id），再开启检查会直接报错ERROR 1822 (HY000): Failed to add the foreign key constraint，且无法自动修复——表会被锁死，直到你手动删掉非法行。
- 仅限单次、可控、离线场景（如ETL、初始化导入）
- 开启前必须确保数据已通过应用层或预校验（例如用
SELECT id FROM customers WHERE id IN (...)提前过滤） - 永远不要在生产服务运行中长期关闭，也不要用它掩盖设计缺陷
InnoDB引擎层外键与SQL层校验的差异正在消失
MySQL 9.6.0起，外键约束逻辑已从InnoDB引擎层上移到SQL层，所有外键检查现在都走统一SQL执行路径，并完整记录到binlog。这意味着：
过去引擎层的某些优化（如部分锁降级）不再适用；但好处是CDC和主从复制终于能准确捕获外键引发的级联变更，不会再丢数据或不一致。不过，这对大批量写入性能没有改善——SQL层校验反而更重，因为要兼容更多语义和复制需求。
所以别指望新版本“自动变快”，该建的索引、该拆的级联、该控的事务粒度，一点都不能少。
真正容易被忽略的点是：外键性能问题从来不是孤立存在的。它总和索引缺失、事务过大、autocommit=1、二级索引过多等问题一起爆发。单点优化很难见效，得通盘看锁、IO、日志、索引四条链路。
