外键校验逐行触发，每行单独查父表并加共享间隙锁；无索引时导致全表扫描和锁竞争，应为外键列显式建索引，禁用外键仅限离线可控场景。
INSERT时外键校验是逐行触发的，不是批量跳过的
哪怕你用INSERT INTO t VALUES (),(),()一次插入 1000 行，MySQL 也不会把这 1000 个外键值去重后查一次父表。它会为每一行单独执行一次存在性检查：查索引（如果有）、加共享间隙锁（S Gap Lock）、返回结果、释放锁。这个过程在父表大或并发高时，IO 和锁竞争会被指数级放大。
常见错误现象：SHOW PROCESSLIST中大量线程卡在Updating或Waiting for table metadata lock；慢日志里出现看似简单的INSERT却耗时数秒。
- 复合外键字段未建对应复合索引 → 单列索引无效，照样全表扫描
- 父表主键无索引（极少见但可能）→ 子表外键检查直接扫父表全表
-
LOAD DATA INFILE导入 → 同样触发逐行校验，不因语法“批量”而跳过
外键字段没索引会导致父表全表扫描+全表S锁
外键列本身不会自动获得高效索引。InnoDB 只在你显式定义PRIMARY KEY或UNIQUE时附带建索引；普通外键列（如orders.customer_id）默认不带索引。没索引时，每次INSERT都要对父表做全表扫描验证存在性，同时持共享锁——这不仅慢，还会阻塞其他事务对父表同一范围的DELETE或UPDATE。
验证方式：EXPLAIN SELECT * FROM parent_table WHERE id = ?看是否type=const且key列有索引名；再查information_schema.INNODB_TRX确认锁持有情况。
- 用
SHOW CREATE TABLE child_table检查外键字段是否已有索引 - 没有就立刻加：
ALTER TABLE child_table ADD INDEX idx_fk_col (fk_col) - 复合外键（如
(order_id, product_id)）必须建顺序一致的复合索引，不能只建单列
SET FOREIGN_KEY_CHECKS = 0 不是性能调优手段，而是高风险维护操作
SET FOREIGN_KEY_CHECKS = 0确实能让INSERT快几倍，但它只是跳过校验，不消除外键本身的结构负担：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，否则后续所有写操作都不受约束 - 执行完立即验证：
SELECT * FROM child_table WHERE fk_col NOT IN (SELECT id FROM parent_table)
高并发写入表建议直接去掉外键
订单流水、日志、埋点这类高频写入表，外键带来的锁竞争和校验开销远大于收益。InnoDB 的行锁在高并发下也扛不住外键引发的额外元数据查找和共享锁等待。
先确认业务是否真需要强一致性：比如“用户注销”必须同步清空其所有订单？还是允许几秒延迟？去掉外键后，在应用层做轻量校验更可控：INSERT前SELECT 1 FROM users WHERE id = ?，失败则拒写。
- 保留外键只用于低频、强一致要求的表（如配置表、权限表）
- 避免
ON DELETE CASCADE——它实际是递归单条删，不是批量优化 - 级联删除改由应用层分批控制：
DELETE FROM child_table WHERE fk_col = ? LIMIT 1000，循环执行
真正拖慢INSERT的从来不是外键这个概念，而是它背后那一套无法合并、无法绕过、且极易被忽略的锁与索引行为。最容易被漏掉的，是外键字段类型与父表主键不一致导致的隐式转换——看着建了索引，实际根本用不上。
