MySQL不推荐使用外键，因其在高并发、大数据量场景下是明确性能瓶颈：每次写操作需跨表查询+加共享间隙锁，引发I/O开销、锁竞争与死锁；分库分表或微服务架构下外键彻底失效；级联操作低效且阻塞热点行；禁用外键检查不可替代合理架构设计。
外键在高并发、大数据量场景下不是“可选优化项”，而是明确的性能瓶颈源——它让每次写操作都多一次跨表查+加锁，而这个开销在QPS超50、单表行数过万时会指数级放大。
INSERT/UPDATE 为什么突然变慢？
每次往子表插入或更新带外键的记录，InnoDB 必须执行一次真实 SELECT 查询去父表确认主键存在，哪怕只是 SELECT * FROM users WHERE id = ?。这不是缓存比对，是实实在在的 I/O + 索引查找。
- 如果
users.id没走索引（比如类型不一致触发隐式转换），直接全表扫描 - 更关键的是，这个查询会在父表对应记录上加 共享间隙锁（Shared Gap Lock），阻塞其他事务对该行的 DELETE 或 UPDATE
- 常见现象：
INSERT INTO orders (user_id) VALUES (123)偶发卡住 200ms+，SHOW ENGINE INNODB STATUS显示大量lock wait timeout
ON DELETE CASCADE 实际是“伪批量”
你以为级联删除是原子高效操作？实际是 InnoDB 先查出所有子表匹配行（比如 5000 条订单），再一条一条触发 DELETE：每条都重新校验外键、加锁、写 binlog、更新索引。
- 对比应用层手动删：
DELETE FROM orders WHERE user_id = ? LIMIT 1000分批执行，总耗时常低于 2 秒；外键级联可能耗时 8~12 秒 - 级联期间父表记录被锁死，其他事务无法更新该用户信息，形成“热点行阻塞”
- 没有并行、无批量合并、不可中断——一旦中途失败，状态难回滚
分库分表或微服务架构下外键彻底失效
MySQL 的外键约束只在单个数据库实例内有效。当 users 表和 orders 表物理分离（跨库、跨实例、跨微服务），外键就只剩语法错误。
- 你无法在
shard_01的users和shard_02的orders之间建外键 - 微服务各自独占数据库，跨服务关联只能靠应用层校验或最终一致性方案（如消息队列 + 补偿事务）
- 强行保留外键，等于提前给自己埋下架构演进的雷——等业务做大要拆库时，必须重写所有外键逻辑
临时禁用外键检查不是性能解法
SET FOREIGN_KEY_CHECKS = 0 是运维手段，不是性能调优方式。它只应在数据导入、结构迁移等可控场景下使用，且必须事后验证数据一致性。
- 禁用后若存在脏数据，后续开启检查会直接报错，甚至导致表无法访问
- 它对日常 INSERT/UPDATE 无加速效果——每个语句仍需走完整流程，只是跳过了校验环节
- 生产环境长期关闭等于放弃数据完整性底线，风险远大于收益
真正容易被忽略的点是：外键带来的锁竞争和死锁，往往在压测阶段不暴露，上线后流量高峰才集中爆发；而那时排查成本极高，因为锁等待链路横跨父子表，且与事务隔离级别、索引覆盖度强耦合。
