高并发场景下禁用外键是互联网公司硬性规范，因其会触发父表查询、共享间隙锁导致写入延迟飙升，ON DELETE CASCADE易引发全表锁定，分库分表后外键失效且不报错，应用层校验更可控、可灰度、可降级。
高并发场景下直接禁用外键是多数互联网公司的硬性规范，不是权衡取舍，而是性能与稳定性的底线要求。
外键会触发额外的父表查询和锁等待
每次向子表插入或更新带外键的字段（如 order_items.order_id），InnoDB 必须确认父表中对应记录存在。这个过程不是简单走索引，而是隐式加共享间隙锁（Gap Lock）在父表目标记录上——哪怕你只插一条订单，它也会锁住 orders.id 对应的那条 users 记录，阻止其他事务删/改该用户。
无序列表呈现关键影响：
- 高并发下单时，大量请求集中操作同一用户（比如主播粉丝抢购），父表锁排队，子表写入延迟飙升
- 即使父表有
PRIMARY KEY或唯一索引，仍需一次额外 I/O 查询 + 加锁，QPS 上万时 CPU 和锁等待明显抬升 -
ON DELETE CASCADE更危险：删一个用户可能触发扫描并删除数万条订单，锁住整张父表
分库分表后外键完全失效
MySQL 的外键约束仅在单实例、单数据库内生效。一旦业务拆分到多个物理库（如 shard_001 存用户，shard_002 存订单），FOREIGN KEY (user_id) REFERENCES users(id) 语法能建成功，但约束不执行——数据库不会跨库校验，也不会报错，数据一致性彻底失控。
此时若保留外键定义，反而制造虚假安全感。真实项目中，外键往往是迁移路上第一个被批量 DROP FOREIGN KEY 的对象，否则 DDL 变更（如修改 users.id 类型）会因依赖关系失败。
应用层校验比数据库外键更可控
放弃外键不等于放弃一致性，而是把控制权从数据库移到代码层，换来的是可灰度、可降级、可监控的校验能力：
- 查用户存在性可用缓存（如 Redis）兜底，避免穿透数据库；外键强制走磁盘查询，没法绕过
- 允许“先占位后补全”：比如创建预订单时
user_id暂为空，后续异步填充，外键会直接拒绝 - 可配置开关：灰度期开启强校验，稳定后降级为异步巡检，外键无法动态关闭
- 错误定位清晰：
User not found比Cannot add or update a child row: a foreign key constraint fails更易排查
真正难的不是去掉外键，而是在应用层补全校验、事务边界、最终一致性修复这三件事。漏掉任意一环，数据就会慢慢腐化——这点比外键本身更值得警惕。
