你真的需要外键吗？
在关系型数据库中是否强制外键约束，实际上是在数据完整性与长期可维护性，对抗写入性能、分片灵活性和迁移复杂度之间做权衡。许多工程师认为约束应当作为默认选择，因为它们能防止微妙的 bug、记录数据模型，并保护那些会比任何单个应用都活得更久的数据；而另一些人则指出，在大型 MySQL 部署和专门架构中，约束会被移除，完整性改由应用代码来保证。讨论还强调，外键在典型规模下很少成为瓶颈，而如果要安全地省略它们，则需要高度的纪律、强大的工具，以及对权衡取舍的清晰理解。
关于外键约束的总体立场
- 强烈的多数观点：对任何非平凡、长期运行的系统，默认使用外键（FK）约束。
- 它们能防止脏数据/孤儿数据，尽早暴露应用程序 bug，并让重构更安全。
- 有几位提到，缺少外键的大型遗留 MySQL / 数百张表系统会变成“数据腐烂”的噩梦，需要脆弱的清理脚本和团队内部知识才能维持。
数据完整性、安全性与文档性
- 外键被比作类型、安全带或受保护内存：你可以不使用它们来编程，但它们能以很低的成本捕捉许多错误。
- 在强约束下，团队可以假设“只要在数据库里，它就是有效的”，把数据库当作堡垒。
- 外键提供了活的数据库模型文档；缺少外键会让人很难理解关系，甚至无法判断某个列到底是不是引用。
性能、规模，以及何时考虑移除外键
- 批评者认为，外键会拖慢高写入/高删除负载，给分库分片和在线模式变更（尤其在 MySQL 中）带来复杂性，并增加锁竞争。
- 其他人则反驳说：
- 大多数应用根本达不到会受此影响的规模。
- 完整性成本总要付出；把检查移到应用代码并不会让它免费，而且还会带来竞态风险。
- 批处理、延迟约束和调优通常可以缓解性能问题。
- 一些超大规模或复杂平台会用自定义完整性层来替代原生外键，但这被描述为高级且专业化的选择。
应用层强制 vs 数据库层强制
- 一派观点：完整性可以在应用层或服务层强制，尤其是在只有一个写入者且访问控制严格的情况下；外键不是必需的。
- 反对一派：多个应用、临时访问以及并发语义，会让在代码中复现数据库保证变得脆弱且容易出错。
软删除与删除行为
- 将
deleted_at软删除与外键结合起来很棘手，尤其是要确保当父记录仍有活跃子记录时不能被软删除。 - 提出的办法包括：统一软删除、把“is_deleted”标志纳入复合外键、将已删除行移动到单独的表，或通过触发器写入审计表。
环境策略
- 有人建议仅在开发/测试环境启用外键，以便发现问题，而在生产环境关闭以提高导入速度。
- 这一做法遭到强烈批评，认为它本末倒置且有风险：真正重要的数据在生产环境，而不是测试环境。