大规模生产环境应默认禁用mysql外键：因其高并发下触发父表共享间隙锁、强制额外i/o查询、on delete cascade退化为低效单条递归删除，分库分表后完全失效却不报错，且隐式锁行为加剧死锁与延迟。
大规模生产环境里，MySQL 外键约束不是“慎用”，而是应默认禁用——它会在高并发写入时触发父表共享间隙锁、强制额外 I/O 查询、级联删除变成单条递归执行，且分库分表后完全失效却不报错。
外键会隐式加共享间隙锁（Gap Lock）
每次向子表插入或更新带外键的字段（如 order_items.order_id），InnoDB 必须确认父表对应记录存在，这个过程会隐式在父表目标索引范围上加 共享间隙锁，而非仅行锁。
- 即使只插一条订单，也会锁住
orders.id = 123对应的那条记录所在间隙，阻塞其他事务对该用户的DELETE或UPDATE - 多个事务同时操作同一用户（如抢购场景），父表锁排队，子表写入延迟飙升，
SHOW ENGINE INNODB STATUS中可见大量lock wait timeout - 锁等待超时由
innodb_lock_wait_timeout控制，默认 50 秒，但业务通常要求 1 秒内响应，实际中常直接失败
ON DELETE CASCADE 实际是逐条递归删除
配置了 ON DELETE CASCADE 并不等于高效批量删，InnoDB 会先全量扫描子表匹配行，再对每一行单独触发 DELETE，每条都重新校验外键、加锁、写 binlog、更新索引。
- 删一个带 1 万订单的用户，外键级联可能耗时 8～12 秒；应用层用
DELETE FROM orders WHERE user_id = ? LIMIT 1000分批执行，总耗时通常低于 2 秒 - 级联期间父表记录被长期锁住，其他事务无法更新该用户信息，形成“热点行阻塞”
- 没有并行处理、无执行计划优化，也无法加 hint 或 force index
分库分表后外键完全失效且不报错
MySQL 的外键约束只在单实例、单数据库内生效。一旦拆库（如 shard_001 存用户、shard_002 存订单），FOREIGN KEY (user_id) REFERENCES users(id) 语法能建成功，但约束不执行。
- 数据库不会跨库校验，也不会报错，数据一致性彻底失控
- 保留外键定义反而制造虚假安全感，真实项目中往往是迁移时第一个被批量
DROP FOREIGN KEY的对象 - DDL 变更（如修改
users.id类型）会因依赖关系失败，而应用层引用关系可灰度、可绕过
外键列有索引也不代表查询高效
InnoDB 强制要求子表外键列必须有可用索引，否则建表失败；但已有索引未必被真正利用。
- 常见错误：父表
id是BIGINT，子表外键列却是INT，导致隐式类型转换，索引失效，触发全表扫描 -
EXPLAIN SELECT * FROM users WHERE id = 123中若type不是const或key列为空，说明外键检查正在走全表 - 外键检查强制走磁盘查询，没法像应用层那样用 Redis 缓存兜底，QPS 上万时 CPU 和锁等待明显抬升
真正难的不是删掉外键语句，而是补上应用层的三件事：强校验入口（含缓存+DB 双读）、明确事务边界（比如预占位是否允许空 user_id）、最终一致性修复机制（如定时巡检孤儿记录）。漏掉任意一环，数据就会缓慢腐化——这点比外键本身更隐蔽、更危险。
