外键基础概念
外键是一个表中的字段，它引用另一个表的主键或唯一键，用于确保两个表之间的数据一致性。
-- 主表：用户CREATETABLEuser(idINTPRIMARYKEYAUTO_INCREMENT,nameVARCHAR(50)NOTNULL);-- 从表：订单（通过 user_id 关联 user.id）CREATETABLEorders(idINTPRIMARYKEYAUTO_INCREMENT,order_noVARCHAR(20)NOTNULL,user_idINT,FOREIGNKEY(user_id)REFERENCESuser(id)-- 外键约束);本质是数据库层面的强制引用完整性检查。
外键约束类型与行为
当主表数据变更时，从表如何响应？MySQL 提供 5 种约束行为：
| 约束类型 | 主表 DELETE | 主表 UPDATE | 使用场景 |
|---|---|---|---|
| CASCADE | 级联删除从表数据 | 级联更新从表外键值 | 强关联数据（用户注销→删除订单） |
| SET NULL | 从表外键设为 NULL | 从表外键设为 NULL | 可选关联（部门删除→员工部门ID置空） |
| RESTRICT | 阻止删除（默认行为） | 阻止更新 | 强保护（有订单时不能删用户） |
| NO ACTION | 同 RESTRICT（SQL 标准） | 同 RESTRICT | 与 RESTRICT 等价 |
| SET DEFAULT | 设为默认值（InnoDB 不支持） | 设为默认值 | InnoDB 引擎无效 |
完整创建语法：
CREATETABLEorders(idINTPRIMARYKEY,user_idINT,FOREIGNKEY(user_id)REFERENCESuser(id)ONDELETECASCADE-- 删除用户时，级联删除订单ONUPDATERESTRICT-- 更新用户ID时，阻止（一般不会更新主键）);外键实现原理
数据字典与元数据
-- 查看外键信息SELECTCONSTRAINT_NAME,TABLE_NAME,COLUMN_NAME,REFERENCED_TABLE_NAME,REFERENCED_COLUMN_NAMEFROMINFORMATION_SCHEMA.KEY_COLUMN_USAGEWHEREREFERENCED_TABLE_NAMEISNOTNULL;InnoDB 在数据字典中维护外键元数据，包括父表、子表、关联列和约束类型。
锁机制（性能杀手）
当插入/更新/删除子表时，InnoDB 会加间隙锁（Gap Lock）保护父表：
-- 场景：orders 表有外键 user_id 引用 user.idBEGIN;INSERTINTOorders(user_id)VALUES(100);-- 子表插入-- InnoDB 隐式加锁：-- 在 user 表的 id=100 记录上加 **共享间隙锁**-- 阻止其他事务删除/更新 user.id=100，防止插入孤儿订单锁范围：
- 主表：user (id 列)
- 插入子表：给主表对应 id 加共享锁
- 删除主表：检查从表是否有引用，加共享锁扫描
- 更新主表 id：给新/旧 id 都加锁
性能影响：
- 高并发写入时，外键检查导致锁竞争加剧
- 删除主表记录需全表扫描从表（无索引时）
外键检查时机
约束检查模式：
-- 会话级设置 SET foreign_key_checks = 0; -- 临时关闭外键检查（危险！） SET foreign_key_checks = 1; -- 开启（默认）批量导入数据时：
-- 先关闭外键检查，加速导入SETforeign_key_checks=0;LOADDATAINFILE'orders.csv'INTOTABLEorders;SETforeign_key_checks=1;-- 完成后务必开启外键的优点
数据一致性保障
-- 无法插入孤儿记录INSERTINTOorders(user_id)VALUES(999);-- ERROR 1452: Cannot add or update a child row-- 无法删除被引用的父记录DELETEFROMuserWHEREid=100;-- ERROR 1451: Cannot delete or update a parent row级联操作简化业务代码
-- 删除用户时，自动级联删除订单、地址、积分ONDELETECASCADE;-- 无需手动写多个 DELETE 语句文档化表关系
外键约束显性定义了表间关系，新开发人员可快速理解数据模型。
外键的缺点（互联网大厂弃用原因）
性能瓶颈
- 锁竞争：高并发下，外键检查间隙锁导致锁等待
- 延迟增加：外键检查增加 5-10% SQL 执行时间
- 级联删除慢：删除主表 1 条记录，可能触发从表百万级级联删除
扩展性差
- 分库分表失效：跨库外键无法检查，ShardingSphere 等中间件不支持外键
- 微服务架构冲突：服务拆分后，跨服务外键无法约束
业务耦合
- 删除主表受阻：业务想软删除用户，但外键阻止
- 热更新困难：修改表结构需先删外键，增加运维复杂度
级联陷阱
-- 误操作：删除 1 个用户，级联删除 10 万订单（无法回滚）DELETEFROMuserWHEREid=1;-- 瞬间删 10 万数据！-- 解决：应用层软删除 + 定时任务清理UPDATEuserSETdeleted=1WHEREid=1;-- 业务层控制大厂最佳实践：去外键化
应用层保证一致性
@ServicepublicclassUserService{@TransactionalpublicvoiddeleteUser(LonguserId){// 1. 先检查是否有订单if(orderRepository.countByUserId(userId)>0){thrownewBusinessException("用户有订单，不能删除");}// 2. 再删除用户userRepository.deleteById(userId);}}软删除 + 定期归档
-- 用户表增加 deleted 字段ALTERTABLEuserADDCOLUMNdeletedTINYINTDEFAULT0;-- 删除操作变为更新UPDATEuserSETdeleted=1WHEREid=100;-- 从表订单保留 user_id，业务查询自动过滤SELECT*FROMordersWHEREuser_idIN(SELECTidFROMuserWHEREdeleted=0);分布式事务（跨服务）
// 使用 Seata / Saga 模式保证最终一致性@GlobalTransactionalpublicvoidcreateOrder(LonguserId){// 1. 调用用户服务（校验用户存在）userService.checkUserExists(userId);// 2. 创建订单orderRepository.save(newOrder(userId));// 3. 异常时全局回滚}什么时候该用外键？
推荐使用场景
- 内部管理系统：并发低、数据一致性要求高
-- 企业内部 ERPCREATETABLEemployee_dept(emp_idINT,dept_idINT,FOREIGNKEY(emp_id)REFERENCESemployee(id)ONDELETECASCADE); - 强关联数据：无孤立记录可能
-- 订单明细与订单头FOREIGNKEY(order_id)REFERENCESorder_header(id)ONDELETECASCADE - 开发规范严格：团队小、运维规范
不推荐场景
- 高并发互联网业务：C2C 电商、社交
- 分库分表架构：ShardingSphere、MyCat 环境
- 微服务架构：跨服务数据无法约束
- 需要柔性事务：允许短暂不一致
性能对比测试
-- 测试环境：MySQL 8.0, 100 万订单, 10 万用户-- 场景 1：插入订单（有外键）INSERTINTOorders(user_id,amount)VALUES(1001,99.00);-- 耗时：1.2ms（检查 user.id=1001 是否存在）-- 场景 2：插入订单（无外键）INSERTINTOorders(user_id,amount)VALUES(1001,99.00);-- 耗时：0.3ms-- 场景 3：删除用户（有外键 + 级联）DELETEFROMuserWHEREid=1001;-- 耗时：500ms（级联删除 10 条订单）-- 场景 4：删除用户（无外键 + 软删）UPDATEuserSETdeleted=1WHEREid=1001;-- 耗时：0.1ms性能结论：外键使写入性能降低 30-50%，删除性能降低 10-100 倍。
外键与索引的关系
外键自动创建索引
-- 建外键时，若 user_id 无索引，InnoDB 自动创建FOREIGNKEY(user_id)REFERENCESuser(id);-- InnoDB 自动：CREATE INDEX user_id ON orders(user_id);手动删除外键索引
-- ❌ 错误：无法删除被外键使用的索引DROPINDEXuser_idONorders;-- ERROR-- ✅ 正确：先删外键，再删索引ALTERTABLEordersDROPFOREIGNKEYorders_ibfk_1;DROPINDEXuser_idONorders;
