需要数据一致性的时候需要，数据做了强关联，后续不好处理，其实系统不怎么迭代的话，是可以使用外键的。
企业内部管理ERP或者CRM外键应该用的多
一些非核心的老系统可能会用，对于新系统来说我觉得没有必须要用的理由。感觉tidb还是不要支持外键的好，一旦支持可能就有开发去用，然后就给dba挖坑了。。。
1 个赞
早期rdbms oracle sqlserver mysql数据库外键使用还是比较常见的，金融类的业务场景，体育赛事赛事赛季表相关的数据都会到，后来发现表维护，关系维护麻烦，在大批量的数据维护场景中性能影响明显，逐步转为业务代码逻辑实现，到现在的NoSQL数据库，包括当前热门的NewSQL TIDB 很多支持分布式事务，分布式锁实现一致性要求， 可以满足的实现业务需求，DBA在听到外键的情况下多数直接拒绝
，在现有的技术能满足的情况首推事务或者业务逻辑替代使用外键
3 个赞
开发小软件，周期短，删除的时候需要提示引用我就会用外键，只是为了方便，别的时候能不用就不用。
业务上比较少使用外键，一般把外键的职能放到程序去实现
外键一般都是通过应用在代码层实现。外键是一种偷懒的用法，
数据一致性检查吧，比如定时任务框架quartz就有
外键可以精简关联数据，减少数据冗余，降低应用代码复杂性，减少了额外的异常处理。但是会有比较大的性能压力，也不利于表结构的更新。
1、强烈要求数据一致性，程序弱化，数据库端强化，表结构改动小，并发不高的场景；
2、频繁的数据装载，但是也严格要求数据库端保持数据一致性；
3、并发少，事务块简单；
4、主键的外键引用字段类型要扩充，原来的数据溢出，没法保存最大的值；
5、子表有触发器需求来更新必要的字段；
6、父表为分区表，有外键的需求；
7、日常并发很高的场景，应该尽量减少相关事务锁的范围和量级。
上面的1、2、3场景，很适合用外键。后面的那几个就不适合用外键，可以放在数据库之外去实现。
1 个赞
外键，一个过气的明星
业务需要，保持数据一致性。
抽奖结果来啦
让我们一起恭喜中奖的两位TiDBer叭:two_hearts:@Mark @LI-ldc
中奖奖品：TiDB 磁带移动充电宝×1
感谢所有参与本次调研的TiDBer！
感谢名单：
@xfworld @Becky_Guo @ealam_小羽 @边城元元 @c4pt0r @wfxxh @Christophe @Chenqi @Myth @Mickyun @Hacker007 @wolf @Kuber @望海崖2084 @neolithic @xiaour @whymalin @dba_wxm @TiDBer_ou2knoWm @数据小黑 @啦啦啦啦啦 @Mark @linjian19811027 @wluckdog @HACK @张雨齐0720 @LI-ldc @阿福Chris @YuchongXU
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。