Mysql外键约束

优点：

1）数据一致性

由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100%保证数据的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性

eg：数据库和应用是一对多的关系，A应用会维护他那部分数据的完整性，系统一变大时，增加了B应用，A和B两个应用也许是不同的开发团队来做的，我们如何协调保证数据的完整性，而且一年以后如果又增加了C应用呢？

2）ER图可靠性

有主外键的数据库设计可以增加ER图的可读性，这点在数据库设计时非常重要

3）使设计更全面

外键在一定程度上说明的业务逻辑，会使设计周到具体全面

4）级联性能未必最低

除非能证明触发器的性能和可维护性比外键更有优，否则凭什么一定要否定外键呢？

5）程序能完全保证安全性吗？

使用应用程序来维护数据完整性，则是严重降低数据库安全性的一种做法。连接字符串里如果有uid和pwd或者类似的这两个东西，可以使用工具获取你数据库的账号，因为每次建立数据库联接的时候都会在网线上以标准格式传递这些信息，从此编码内的任何保证都是空的。

约束：

1）程序逻辑

某些程序逻辑中，程序的逻辑已经足够保证完整性，我会在存储过程或包等地方做严谨的判断；

2）性能问题

这是很多人不喜欢用的关键原因，比如一个业务流水表，频繁插入数据，如果这个表身上有3个外键，那么每次插入一条，就必须对这3个外键对应的3个表做相应的查找判断有无对应数据，如果这3个表也很大，那就这3个表的判断时间就很长，虽然外键指向的关联表的字段肯定是索引，但是我觉得很多时候，这样的判断本来就在程序里控制好了，通过外键再判断一次，就是降低性能；而且其实有的地方判断不判断也无所谓，但是用了外键，就必须花时间去判断，无论oracle内部多么优化外键对于数据的检索速度，他总是一个不小的消耗；

3）维护麻烦

很多公司的软件都是定制的，这种定制的东西，随意性相对较大，项目开发实施过程中，需要经常对表修修补补；还有就是业务逻辑有bug或者其他情况，需要经常手工维护数据，有错综复杂的外键关联着，很是麻烦；

4）外键定死了先后生成关系

外键定死了两个表之间数据的先后生成关系，最常见的是单据主从表，有的时候，在生成单据的时候，是先生成明细，再生成主表；如果定死了外键，这个就没法实现；