数据库外键约束要不要用？有什么优缺点？

简化版

外键约束能由数据库保证引用完整性，防止子表引用不存在的父表记录，也能配合级联更新或删除。但高并发互联网业务有时不用物理外键，而是在应用层和数据治理层维护关系，以换取更灵活的发布、分库分表和批量处理能力。

详细版

外键优点：

• 数据库层保证引用完整性；
• 防止脏数据，比如订单引用不存在的用户；
• 约束语义清晰，表关系更容易理解；
• 可配置级联更新、级联删除或限制删除。

外键缺点：

• 写入、删除、更新时需要检查约束，有额外成本；
• 级联操作误用可能造成大范围影响；
• 分库分表、跨服务数据库很难使用物理外键；
• 上线迁移和批量导入时更受约束；
• 高并发下可能增加锁等待和耦合。

是否使用外键，要看业务对强一致的要求、数据库规模、团队治理能力和架构形态。

完整版教学

一、外键解决的是引用完整性

引用完整性指的是：子表里的引用必须能在父表中找到。

比如：

orders.user_id -> users.id

如果没有约束，程序 bug 可能插入一个 user_id=999 的订单，但用户表里根本没有这个用户。外键可以在数据库层拒绝这种写入。

二、外键的价值是把规则下沉到数据库

应用层校验依赖每个入口都写对逻辑。数据库外键则无论哪个应用、脚本、后台任务写入，都必须满足约束。

这对中后台系统、金融系统、数据质量要求高且库内关系稳定的系统很有价值。它让数据规则不是停留在代码约定里，而是由数据库强制执行。

三、为什么很多互联网业务不用物理外键

不用外键并不代表不需要关系，而是不用数据库物理约束来强制。

常见原因：

• 业务拆成多个服务，数据不在同一个库；
• 分库分表后父子表可能不在同一节点；
• 高并发写入时不希望每次都做额外约束检查；
• 批量导入、历史修复、灰度迁移需要更灵活；
• 删除通常做软删除，不希望级联物理删除。

这时会通过应用层校验、唯一索引、状态机、离线巡检、数据修复任务来维护关系。

一个实际判断方法是看关系边界是否会跨库、跨服务、跨团队发布。如果 orders.user_id 和 users.id 永远在同一个单体库里，并且删除用户必须受订单约束，外键收益很直接；如果订单库和用户库由两个服务独立发布，物理外键无法跨库生效，强行追求外键反而会破坏服务边界。

四、不用外键也要有“逻辑外键”

很多项目说“不建外键”，最后变成“没有任何约束”，这很危险。即使不用物理外键，也应该在设计上明确：

• 哪些字段引用哪些表；
• 是否允许父记录删除；
• 删除时子记录怎么办；
• 是否需要唯一约束；
• 是否有巡检任务发现孤儿数据。

表结构、接口文档、ER 图和代码模型里都要表达这些关系。

五、级联删除尤其要谨慎

外键支持 CASCADE 等动作，但级联删除很容易造成意外。比如删除一个用户，级联删除订单、支付记录、发票记录，这通常不是业务想要的。

在业务系统中，删除经常意味着禁用、归档、软删除，而不是物理删除。级联操作更适合关系明确、规模可控、误删可恢复的场景。

六、面试怎么答更稳

不要简单说“外键影响性能，所以不用”。更好的回答是：

外键能保证数据库层引用完整性，但会增加写入约束和架构耦合。单体系统、强一致中后台可以考虑使用；分库分表、微服务、高并发核心链路通常用逻辑外键加应用校验和数据巡检。

这样既承认外键价值，也说明不用外键的工程原因。

七、常见误区与追问

场景	更适合的做法	原因
单库中后台、数据关系稳定	可使用物理外键	数据质量收益大，架构耦合可控
分库分表、跨服务数据	逻辑外键 + 应用校验	物理外键跨库不可用，发布和迁移更灵活
删除用户、订单、支付等核心记录	避免级联硬删除	这些记录通常有审计、财务或合规价值

记忆钩子：外键不是“性能开关”，而是“数据库层关系契约”。不用物理外键时，必须补上逻辑外键、唯一约束、巡检和修复机制。

假设订单写入峰值是每秒 5000 条，每条订单都要检查 users(id) 是否存在，外键检查会让写路径多一次约束判断；如果用户表和订单表后来拆到不同库，物理外键就无法继续表达这个关系。反过来，一个日写入只有几万条的后台系统，如果没有外键和唯一约束，脚本误导入 200 条孤儿明细，排查成本可能远高于外键带来的写入成本。

• 误区：互联网系统不用外键，所以外键没有价值。 不用物理外键通常是因为分库分表、微服务和高并发写入的工程取舍，不代表引用完整性不重要。
• 误区：建了外键就一定不会有脏数据。 外键只能保证引用存在，不能保证业务状态正确；例如订单引用的用户存在，但用户可能已被冻结。
• 误区：级联删除可以省很多代码。 核心业务里级联硬删除风险很高，删除用户时级联删订单、支付记录通常是严重事故。
• 追问：不用外键如何证明数据关系是可信的？ 要说明逻辑外键文档、应用层校验、唯一索引、删除限制、离线孤儿数据巡检和修复任务。
• 追问：外键会不会影响性能？ 会增加写入、更新、删除时的约束检查和锁等待可能，但影响大小取决于数据量、索引、并发和操作类型，不能笼统说一定很慢。
• 追问：外键字段要不要建索引？ 子表外键列通常需要索引，否则父表删除或更新时检查子表引用会扫描更多数据，容易放大锁等待。

八、加强记忆

外键的本质是数据库替你守住引用完整性。用外键，数据更稳但耦合更强；不用外键，架构更灵活但必须用逻辑关系、应用校验、唯一索引和巡检兜底。别把“不建物理外键”理解成“关系随便写”。