共计 855 个字符，预计需要花费 3 分钟才能阅读完成。
背景
目前很多公司都不思考退出外键了，很多人工作中也不怎么应用外键了，毕竟每次做 DELETE 或者 UPDATE 都必须思考外键束缚，会导致开发的时候很苦楚, 测试数据极为不不便。
在笔者看来，在相应的场景下，如果应用的一个性能弊大于利，可能就不会抉择了。所以是否应用外键取决相应的场景，也不可去齐全摈弃外键。
为什么会很少应用外键呢？
目前应用外键的确存在一些不便，这也是大多数人不应用的起因所在。我具体总结了会存在这么几个起因：
1、减少数据库压力
外键等于把数据的一致性事务实现，全副交给数据库服务器实现，并且有了外键，当做一些波及外键字段的增、删、更新操作之后，须要触发相干操作去查看，而不得不耗费资源。
2、死锁问题
若是高并发大流量事务场景，应用外键还可能容易造成死锁。
3、开发不不便
有外键时，无论开发还是保护，须要手工保护数据时，都不太不便，要思考级联因素。
4、数据刷库
理论开发过程中，免不了要常常刷库，导入或删除数据，外键的存在会让表删除或插入失败（表数据变更有程序要求）。
5、外键保护
随着我的项目的迭代，表之间的关系也会发生变化，比方有个外键须要删除；或是要新增一个外键，但因为现有数据不准，导致外键加不下来，长此以往，ER 图也不能残缺的显示表关系，这 ER 图看还是不看？
外键真的就没有用了吗？
存在即正当，每一个产品，每一个性能既然存在，在某些中央也是存在劣势的。笔者总结了一下外键的几个劣势点：
1、数据库的一致性
由数据库本身保证数据一致性、完整性会更牢靠，程序很难 100%保证数据的一致性、完整性，而用外键即便在数据库服务器当机或者呈现其余问题的时候，也可能最大限度的保证数据的一致性和完整性。
2、ER 图可靠性
有主外键的数据库设计能够减少 ER 图的可读性（也有特地的公司产品特地重视的这一方面）。
总结
1、如是单机且低并发，也不须要性能调优，再或者不能用程序保证数据的一致性，完整性，能够应用外键，如学校的，保证数据的一致性与残缺，基数也不大。
2、如果为了高并发，分布式，使零碎性能更优，以及更好保护，则不要去应用外键。