一、问题引入
学过数据库的同学都知道外键，外键能够保证数据的一致性。比如一个学生属于一个班级，班级和学生的关系是一对多，如果你删除了一个班级，那么这个班级中的学生肯定得跟着删除，不然就会产生一群无组织的学生。以往做项目的时候，外键是肯定得用的，不用外键是万万不可能的。
可是有一天偶然看到书上说不建议使用外键，神马(O_o)??还有这样的操作？那该怎么去保证数据一致性啊，不会产生很多脏数据吗？想想就头大。不过人家书的作者技术肯定比我高多了，既然这样说，肯定有他的道理。每当我听到一个观点时，我都不会急着去反驳否定它，我喜欢自己私底下先搞清楚来，这样才有发言权。
二、建还是不建？
1、必须建啊
既然人家数据库团队提供了外键这么一个功能，那肯定不是鸡肋功能，不然费这么大劲维护干嘛。
优点：
（1）实现表与关联表之间的数据一致性；
（2）可以迅速的建立一个可靠性非常高的数据库结构，而不用让应用程序层去做过多的检查；
（3）可以提高系统鲁棒性、健壮性；
（4）可以实现开发人员和数据库设计人员的分工；
缺点：
（1）数据库需要维护外键的内部管理；
（2）外键等于把数据的一致性事务实现，全部交给数据库服务器完成；
（3）有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源；
（4）外键还会因为需要请求对其他表内部加锁而容易出现死锁情况；
（5）容易出现数据库I/O的瓶颈；
2、不建，有啥好建的
说实现，现在我做项目都不用外键了。
优点：
（1）减少了数据库表与表之间各种关联的复杂性；
（2）牺牲应用服务器资源，换取数据库服务器的性能；
（3）将主动权把控在自己手里；
（4）去掉外键相当于优化数据库性能；
缺点：
（1）所有外键的约束，需要自己在逻辑层自己实现；
（2）会出现数据错误覆写，错误数据进库的情况；
（3）消耗了服务器的性能；
（4）业务层里夹带持久层特性，耦合；
不使用外键，就得自己在逻辑层保证数据一致性，所以就得把情况考虑清楚，比如删除一条记录的时候得进行连带的删除，不然很容易出现脏数据。
3、总结
1. 互联网行业：不推荐使用外键
用户量大，并发度高，为此数据库服务器很容易成为性能瓶颈，尤其受IO能力限制，且不能轻易地水平扩展；
若是把数据一致性的控制放到事务中，即让应用服务器承担此部分的压力；
应用服务器一般都是可以做到轻松地水平的伸缩；
2. 传统行业：可以使用
软件应用的人数有限，换句话说是可控的；
数据库服务器的数据量也一般不会超大，且活跃数据有限；
