外键在高并发写入时显著拖慢insert/update，因每次操作需查父表并加共享间隙锁，引发i/o与锁等待；级联删除非批量而是单条递归执行，效率低下且易造成热点行阻塞；分库分表或异构数据库中外键失效，一致性需应用层可控保障。
外键在高并发写入时会拖慢INSERT/UPDATE
每次插入或更新子表记录，InnoDB 都要查父表确认外键值存在，并加共享间隙锁。这不是走缓存的比对，而是真实执行一次 SELECT ——哪怕父表主键有索引，也会触发额外 I/O 和锁等待。
常见错误现象：INSERT INTO orders (user_id) VALUES (123) 偶发卡住 200ms+；SHOW ENGINE INNODB STATUS 显示大量 lock wait timeout 或 waiting for table metadata lock。
- 验证方式：用
EXPLAIN SELECT * FROM users WHERE id = 123看type是否为const、key列是否有索引名 - 如果父表
id是VARCHAR而子表user_id是INT，隐式类型转换会让索引失效，直接全表扫描 -
innodb_lock_wait_timeout默认 50 秒，但业务通常要求响应在 1 秒内，超时即失败
ON DELETE CASCADE 实际是单条递归删，不是批量优化
你以为级联删除能高效清空子表？InnoDB 先查出全部匹配行（比如 5000 条订单），再一条一条 DELETE，每条都重新校验外键、加锁、写 binlog、更新索引 —— 没有合并、没有并行。
对比应用层手动删：DELETE FROM orders WHERE user_id = ? 一条语句搞定，还能加 LIMIT 分批，执行计划可控。
- 删一个带 1w 订单的用户：外键级联常耗时 8~12 秒；手动分 10 批、每批 1000 条，总耗时通常低于 2 秒
- 级联期间父表那条记录被锁住，其他事务无法更新该用户信息，形成“热点行阻塞”
-
ON UPDATE CASCADE更危险——更新主键在生产环境几乎不用，极易引发数据错乱
分库分表或微服务下外键直接失效
MySQL 外键只在单机单库生效。一旦 user 表和 order 表不在同一实例，或者分别部署在 MySQL/TiDB/MongoDB 上，FOREIGN KEY 语法就报错：ERROR 1215 (HY000): Cannot add foreign key constraint。
试图用“逻辑外键”补救，但缺乏统一校验入口：异步任务、离线脚本、DBA 直连等非主路径容易漏掉。
- 级联语义断裂：删用户 → 删订单 → 删支付记录 → 删日志，这个链路无法原子保证
- 某电商曾用
ON DELETE CASCADE清理测试账号，结果误删了生产环境中同 ID 的正式订单归档表记录 - ShardingSphere、MyCat 等中间件不支持跨节点外键约束，硬加等于白加
真正该纠结的不是“用不用”，而是“谁来负责一致性”
外键把一致性校验强耦合进数据库层，而现代系统需要的是可伸缩、可观测、可灰度的控制能力。应用层校验虽然多写几行代码，但能打日志、埋点、降级、限流、异步补偿。
如果你的场景是单体架构、QPS ON DELETE RESTRICT 作为兜底尚可接受；否则，优先用索引 + 应用校验 + 定期巡检组合替代。
最容易被忽略的一点：外键列没索引会导致建表失败，但已有表加了索引也未必生效——比如字段类型不一致、字符集不同、或用了函数索引却没在查询中对应使用。
