从事程序员工作一开始，公司的开发规范就参照阿里的开发规范，其他不说，这次就说说不使用外键，而是用代码逻辑处理相关约束这个事情吧。
我觉得阿里有这样的规范应该是考虑到服务多，分库分表下外键基本上不可用了，但是当涉及体量不大，即使是多服务，但是也没有到分库分表的情况，那这种情况下我觉得使用外键还是不错的，当删除和更新是就不需要开发人员去考虑写逻辑，只要前期表设计的合理，这些容易让开发人员忽略的事情就可以交给数据库去做了。
我最近在做自己的一个小项目，我开始从头捡起了多年未使用的外键，因为我不需要考虑分表，这种情况下写代码真的省心好多，以前在写删除或者更新的时候还得自己考虑到位，保证不出现 “孤儿数据”，现在根本不需要。
不知道大家平时会给自己的项目使用外键吗？如果不使用是为什么？如果使用了你觉得带来的开发收益大不大？
 |
keerNov 1, 2025
1
基本上不用。就算用了，代码也要做一下。 所以干脆不用了
不过现在如果 AI 帮我把表建好了，给的 sql 有就用，没有就不用。 |
 |
SayHelloHiNov 1, 2025
2
看到老外的项目 里面好多 FK
|
 |
qviqviNov 1, 2025
3
可以用，不会太影响性能
|
 |
leodingNov 1, 2025
4
目前主要是数据库设计阶段做 ER 图时会加入外键，方便确认表之间的关系，但是在导出建表语句时会忽略外键
|
 |
MIUIOSNov 1, 2025
5
多此一举的东西
|
 |
ragnaroksNov 1, 2025
6
自己的项目会用，用性能降低换满足洁癖和无后顾之忧；公司的项目不用，说不定明天就改需求了
|
 |
7
用。
早期不用外键的原因： 1. 和其他功能不兼容，例如分片（驳斥：很多问题只在早期 MySQL 中存在，PostgreSQL 大概率并没有相关问题） 2. 影响性能（驳斥：对性能影响很小。而且如果真的存在某条高频语句，你确保不会出现问题，希望外键不要做无用的检查，现代数据库都允许你针对这单条语句禁用一致性检查，从而保持性能。另外，外键约束也会帮助某些连表查询的自动优化，实际上可能有助于提升性能） 3. 人工维护数据时必须停机（驳斥：对整个数据库临时禁用一致性检查，就能在线维护数据） 4. 外键功能太弱，不满足业务需求（这个完全看特定场景了，如果不能满足业务需求那没什么好说的） |
 |
8
阿里的规范不一定适合所有公司，他们的体量普通公司达不到，他的规范很明显是把 MySQL 打平成普通的数据存储引擎了，摒弃了很多 MySQL 的特性，美其名曰提升性能。
本质上是 RD 和 DBA 争话语权的问题。 |
 |
9
自从阿里系“毕业”的阿狗阿猫们进入传统行业信息化并拿到话语权之后……作为一个并不强势的甲方里的信息化工作人员，我已经绝望了。不接受也得接受，反正换谁来开发都这一股子把 100 个并发的业务系统当 100 万个并发的点赞系统来做的烂德性。
|
|
adoalNov 1, 2025
10
@512357301 早期的 MySQL 里用各种所谓高级特性（其实就是特么的很标准的 SQL 特性）确实对性能影响比较大。现在的版本好一些，但也不一定。相对来说要用所谓高级特性还是选 PG 比较稳妥。
|
 |
yungo8Nov 2, 2025 via Android
11
不爱用，删数据太麻烦，一大堆的关联表，不设的话有游离的脏数据就脏数据吧。反正已经烂到根了
|
 |
AkinoKaedeChanNov 2, 2025
12
神奇的 MySQL 外键会影响索引
|
 |
13
@adoal 嗯，虽然 mysql 没有给我带来多大的麻烦，但我已经开始逐渐开始使用 pg 来代替 mysql 了
|
 |
ChenSinoNov 2, 2025
14
都是 sql 上手动写联表了，反正我从来没用过
|
 |
realpgNov 2, 2025
15
mysql 项目 外键仅用于必须高强度自动 cascade 的场景
|
 |
16
月经问题来来回回的问，先接到需要有必要去掉外键这种白捡功能的大工程再考虑也不迟
|
 |
programMrxuNov 2, 2025
17
看使用框架吧，如果使用 Django 还是需要加一些外键的，如果使用 flask ，那其实加不加就无所谓了
|
 |
bronyakakaNov 2, 2025
18
@programMrxu django 也不用给表加物理外键，模型定义下就行了
|
 |
lysShubNov 2, 2025
19
高级特性都不用
|
 |
yjxjnNov 2, 2025
20
阿里规范只适用于很典型互联网公司，而且业务不复杂（相对于传统制造业的业务来说）。
外企路过，FK 必须用！ |
 |
yinminNov 2, 2025 via iPhone
21
不要用“外键约束”，否则项目做数据维护的时候，太麻烦了，数据库运维要疯掉的
|
 |
LockroachNov 3, 2025
23
用 ORM 的话外键很方便，反正也没有百万级用户，爱怎么来怎么来
|
|
programMrxuNov 3, 2025
24
@bronyakaka 模型定义了物理外键，在迁移数据库的时候，就会生成表外键了。
|
|
bronyakakaNov 3, 2025
25
@programMrxu #24 模型可以指定参数，不会生成
|
 |
lyxxxh2Nov 3, 2025
26
不用,单纯嫌维护麻烦。
至于孤儿数据,存在就存在呗,没强迫症。 |
|
lyxxxh2Nov 3, 2025
27
@bronyakaka
你们把"外键"和"外键约束"当作同个东西了? |
|
bronyakakaNov 3, 2025
28
@lyxxxh2 #27 题目问的就是外键约束，我讨论的不也是这个吗？
|
 |
back0893Nov 3, 2025
29
不会用 db 的约束 基本没有用过
|
 |
loloXNov 3, 2025
30
早期做项目用过，后来有了 ORM 基本就没用过了。作为程序员，还是很希望这些约束都在一个地方管理。
|
 |
guanguanupupNov 3, 2025
31
从来没用过，有关联字段就行了
|
 |
UN2758Nov 3, 2025
32
写 web crud 的同学，假如并发体量低于 1000qps,用外键在遇到关联查询不是省心很多吗
|
2
Select Language