10个人里有9个人建议我不要用外键约束，外键约束真的那么麻烦？

• 没有专业 dba 的情况，数据库就单纯存储数据，不要有逻辑，不然不方便维护。
• 还有性能问题，在高并发大流量事务场景，使用外键更容易造成死锁。
• 比起外建约束我更推荐： 快速入门《Laravel 8 中文文档》

同意楼上观点。
互联网开发的背景下，并发是常有的事，外键容易造成死锁。

后端几乎控制所有的业务逻辑，如果使用外键，其实将应用程序应该执行的判断逻辑转移到了数据库上。那么这意味着一点，数据库的性能开销变大了，那么这就对DBA的要求就更高了。很多中小型公司由于资金问题，并没有聘用专业的DBA，因此他们会选择不用外键，降低数据库的消耗。 相反的，如果该约束逻辑在应用程序中，发现应用服务器性能不够，可以加机器，做水平扩展。如果是在数据库服务器上，数据库服务器会成为性能瓶颈，做水平扩展比较困难。

外键和其他任何技术一样，有坑也有优点。很多人不分青红皂白不问业务需求就说不要用外键，我觉得纯粹是误导新手，大厂有自己的业务场景，人家是知道用不用外键其中的取舍，有的人就只看到了结果，大厂不用我就不用。工程师要有自己的判断力，有自己的看法才能成长，跟风永远只能停留在初级工程师水平。

回到题主的问题，外键的坑远不止你说的这几点，网络上也有很多相关的资料，我就不在这复制粘贴了。

不仅仅是外键，很多技术的坑即使你看到别人写的资料也不会有什么感受，只有自己亲自踩过一遍才会记忆深刻，你才会知道这里为什么用外键，应该用哪种外键。等你踩的坑足够多，有了足够多的思考，才会成为一个高级工程师。

对，外键确实是很方便，扩展很麻烦。迭代产品是很容易出现不方便得情况，还有就是MySQL里面得json也是一样，我都是踩过坑的，牛哥。

10人里9个人建议不使用外键，我觉得不对，至少应该是100人力99人不推荐使用外键。

手动 狗头

外键挺难维护的，现在都有ORM了，外键除了非常强的业务关联要求，一般都不推荐。 至少互联网业务没有非外键不可的。

在项目只有一个数据库时，上了外键。这时你的业务发展，需要拆分数据库，这时候外键就是成了制约了。

一般我们只用逻辑的外键，从来不用物理外键约束，觉得难维护，各种坑，真心没必要给自己找麻烦……

外键有时候在需要手动维护数据时就是坑，或者当主表没了数据时保留附表数时就会很烦了

还有一个人不是程序员吗？