[讨论] 大家的项目中会使用外键约束吗？

[hubianluanma]

从事程序员工作一开始，公司的开发规范就参照阿里的开发规范，其他不说，这次就说说不使用外键，而是用代码逻辑处理相关约束这个事情吧。

我觉得阿里有这样的规范应该是考虑到服务多，分库分表下外键基本上不可用了，但是当涉及体量不大，即使是多服务，但是也没有到分库分表的情况，那这种情况下我觉得使用外键还是不错的，当删除和更新是就不需要开发人员去考虑写逻辑，只要前期表设计的合理，这些容易让开发人员忽略的事情就可以交给数据库去做了。

我最近在做自己的一个小项目，我开始从头捡起了多年未使用的外键，因为我不需要考虑分表，这种情况下写代码真的省心好多，以前在写删除或者更新的时候还得自己考虑到位，保证不出现 “孤儿数据”，现在根本不需要。

不知道大家平时会给自己的项目使用外键吗？如果不使用是为什么？如果使用了你觉得带来的开发收益大不大？

[keer]

基本上不用。就算用了，代码也要做一下。 所以干脆不用了

不过现在如果 AI 帮我把表建好了，给的 sql 有就用，没有就不用。

[SayHelloHi]

看到老外的项目 里面好多 FK

[qviqvi]

可以用，不会太影响性能

[leoding]

目前主要是数据库设计阶段做 ER 图时会加入外键，方便确认表之间的关系，但是在导出建表语句时会忽略外键

[MIUIOS]

多此一举的东西

[ragnaroks]

自己的项目会用，用性能降低换满足洁癖和无后顾之忧；公司的项目不用，说不定明天就改需求了

[w568w]

用。

早期不用外键的原因：

1. 和其他功能不兼容，例如分片（驳斥：很多问题只在早期 MySQL 中存在，PostgreSQL 大概率并没有相关问题）

2. 影响性能（驳斥：对性能影响很小。而且如果真的存在某条高频语句，你确保不会出现问题，希望外键不要做无用的检查，现代数据库都允许你针对这单条语句禁用一致性检查，从而保持性能。另外，外键约束也会帮助某些连表查询的自动优化，实际上可能有助于提升性能）

3. 人工维护数据时必须停机（驳斥：对整个数据库临时禁用一致性检查，就能在线维护数据）

4. 外键功能太弱，不满足业务需求（这个完全看特定场景了，如果不能满足业务需求那没什么好说的）

[512357301]

阿里的规范不一定适合所有公司，他们的体量普通公司达不到，他的规范很明显是把 MySQL 打平成普通的数据存储引擎了，摒弃了很多 MySQL 的特性，美其名曰提升性能。
本质上是 RD 和 DBA 争话语权的问题。

[adoal]

自从阿里系“毕业”的阿狗阿猫们进入传统行业信息化并拿到话语权之后……作为一个并不强势的甲方里的信息化工作人员，我已经绝望了。不接受也得接受，反正换谁来开发都这一股子把 100 个并发的业务系统当 100 万个并发的点赞系统来做的烂德性。

[adoal]

@512357301 早期的 MySQL 里用各种所谓高级特性（其实就是特么的很标准的 SQL 特性）确实对性能影响比较大。现在的版本好一些，但也不一定。相对来说要用所谓高级特性还是选 PG 比较稳妥。

[yungo8]

不爱用，删数据太麻烦，一大堆的关联表，不设的话有游离的脏数据就脏数据吧。反正已经烂到根了

[AkinoKaedeChan]

神奇的 MySQL 外键会影响索引

[hubianluanma]

@adoal 嗯，虽然 mysql 没有给我带来多大的麻烦，但我已经开始逐渐开始使用 pg 来代替 mysql 了

[ChenSino]

都是 sql 上手动写联表了，反正我从来没用过

[realpg]

mysql 项目 外键仅用于必须高强度自动 cascade 的场景

[june4]

月经问题来来回回的问，先接到需要有必要去掉外键这种白捡功能的大工程再考虑也不迟

[programMrxu]

看使用框架吧，如果使用 Django 还是需要加一些外键的，如果使用 flask ，那其实加不加就无所谓了

[bronyakaka]

@programMrxu django 也不用给表加物理外键，模型定义下就行了

[lysShub]

高级特性都不用

[yjxjn]

阿里规范只适用于很典型互联网公司，而且业务不复杂（相对于传统制造业的业务来说）。
外企路过，FK 必须用！