阿里JAVA规范
不得使用外键与级联，一切外键概念必须在应用层解决。
外键的优缺点
缺点：每次做DELETE或者UPDATE都必须考虑外键约束，会导致开发时很痛苦，测试数据极为不方便。
优点：保证数据的完整性和一致性，级联操作方便，数据的一致性交给数据库，代码量小。
外键案例分析
如下图所示，订单表有订单id和其他属性，订单明细表有订单明细id、订单id(外键)和其他属性。
1.性能问题
额外的数据一致性校验查询。当每一次向订单明细表添加数据时，会检查订单表里是否存在对于的外键约束数据id是否存。
2. 并发问题
**外键约束会启用行级锁，主表写入时会进入阻塞。**每一次在订单明细表插入数据会检查订单明细表的记录，此时会给该订单id添加一个读锁。在并发条件下，如果此时甭管什么原因，此时有个请求需要修改订单表的订单 ID ，此时订单表就会开启一个写锁。那么此时订单明细表就会进入一个阻塞的状态，就行进行一个线程的挤压，进而引发系统崩溃。
3.级联删除问题
多层级联删除会让数据变得不可控，触发器也严格被禁用。
数据关系如下图所示，订单表里有订单类型的外键，订单明细表里有订单表的外键。
如果此时我们想删除订单类型，应为订单表与订单类型表存在外键约束关系，那么对于的订单表里的此类型的订单都将会被删除，订单明细表的明细也将会删除。如果存在更多的外键约束关系，则会删除一连串的数据，此时就会变得不可控。这好比一个树，订单类型表是树根，订单表是树枝，订单明细表是树叶，如果删除树根，则树枝和树叶也会被删除，那结果太可怕了。
这些操作都是在数据库层面发生的，都是无法追溯的，是一件很麻烦的事。所以在实际开发中数据库层面的外键约束是严令禁止的。
4.数据耦合和迁移
数据库层面数据关系产生耦合，数据迁移维护困难。
如果某一天，订单明细表的数据量过大，基于 MySQL 本身的性能应用已经不足以支持相对应的业务需求。此时计划将订单明细数据迁移到 HBASE 这样的大数据数据库进行存储。
那么此时是不是需要将原有的主外键约束关系给去掉，之后又如何保证数据的一致性问题呢，此时只能通过程序层面进行约束，这是不是又回到了应用层面。
在实际的项目经验过程中，随着业务发展，有些业务数据就会非常大，因为MySQL关系型数据库本身的性能问题，此时有些数据就会进行一些迁移，这是非常常见的，而此时就需要在应用层面确保数据的一致性，所以也就是有些公司为什么不推荐使用外键约束的原因。
