高并发下禁用外键是硬性规范，因其触发父表共享间隙锁致写入延迟飙升、on delete cascade引发全表锁定、分库后外键失效且不报错，应用层校验更可控可降级。
高并发下外键会触发父表间隙锁，导致写入延迟飙升
每次向子表插入带外键的记录（如 INSERT INTO order_items (order_id)），InnoDB 必须确认 orders.id 存在。这个过程不是简单查索引，而是隐式加 共享间隙锁（Shared Gap Lock） 在父表对应记录上——哪怕只插一条，也会锁住 orders 表里那条订单记录，阻塞其他事务删/改它。
常见错误现象：INSERT 偶发卡住 200ms+，SHOW ENGINE INNODB STATUS 显示大量 lock wait timeout 或 waiting for table metadata lock。
容易踩的坑：
- 热点用户/商品被高频操作时，父表锁排队，子表写入 QPS 直接掉 30% 以上
- 即使父表有主键索引，仍需一次额外 I/O 查询 + 加锁，QPS 上万时 CPU 和锁等待明显抬升
-
innodb_lock_wait_timeout默认 50 秒，但业务通常要求 1 秒内响应，锁等待直接超时失败
ON DELETE CASCADE 实际是逐条删除，不是批量优化
外键级联删除看起来省事，实际执行逻辑是：先全量扫描子表匹配行（比如 5000 条订单），再对每条执行一次 DELETE，每条都重新校验外键、加锁、写 binlog、更新索引——没有合并、没有并行。
对比应用层手动删：DELETE FROM orders WHERE user_id = ? 一条语句搞定，还能加 LIMIT 分批。
使用场景举例：用户注销需清空全部订单，且订单表无分区、无归档策略。
性能影响：
- 删一个带 1w 订单的用户，外键级联可能耗时 8~12 秒
- 手动删分 10 批、每批 1000 条，总耗时常低于 2 秒
- 级联期间父表记录被锁住，其他事务无法更新该用户信息，形成“热点行阻塞”
分库分表后外键完全失效，且不报错
MySQL 的外键约束只在单实例、单数据库内生效。一旦业务拆到多个物理库（如 shard_001 存用户，shard_002 存订单），FOREIGN KEY (user_id) REFERENCES users(id) 语法能建成功，但约束根本不执行——数据库不会跨库校验，也不会报错。
此时保留外键定义，反而制造虚假安全感。真实项目中，外键往往是迁移路上第一个被批量 DROP FOREIGN KEY 的对象，否则 DDL 变更（如修改 users.id 类型）会因依赖关系失败。
容易踩的坑：
- 开发环境有外键、线上已分库，测试通过但线上数据悄悄腐化
- DBA 误以为外键还在起作用，排查数据不一致问题时绕远路
- 外键列类型变更需同步父表，而分库后父表可能在另一套运维体系下，协调成本极高
应用层校验比数据库外键更可控、可灰度、可降级
放弃外键不等于放弃一致性，而是把控制权从数据库移到代码层，换来的是可监控、可开关、可兜底的校验能力。
关键差异：
- 查用户存在性可用 Redis 缓存兜底，避免穿透数据库；外键强制走磁盘查询，没法绕过
- 允许“先占位后补全”：比如创建预订单时
user_id暂为空，后续异步填充，外键会直接拒绝 - 可配置开关：灰度期开启强校验，稳定后降级为异步巡检，外键无法动态关闭
- 错误定位清晰：
User not found比Cannot add or update a child row: a foreign key constraint fails更易排查
真正难的不是去掉外键，而是在应用层补全校验、事务边界、最终一致性修复这三件事。漏掉任意一环，数据就会慢慢腐化——这点比外键本身更值得警惕。
