闭关修行中......
外键是约束，既然是约束肯定就会增加额外的开销。例如书中常见的示例，学生选课系统，学生表和课程表，中间肯定会有一个学生课程关联表。如果添加了外键约束，你在删除某个课程的时候，肯定会先检查这个课程是不是有学生已经选了，不然你删除后学生选的那个课程会找不到而引发错误。
不明白为什么要反模式，省略外键约束能使得数据库设计更加简单、灵活，或者执行更加高效，但你还是不得不在其他方面付出相应的代价，必须增加额外的代码来手动维护引用完整性。本来数据库一个约束键可以解决的，现在还要写一段代码去维护。而且手动写代码维护判断，也是一种约束，也会有性能损耗，只不过是在逻辑层面，和数据库相比不会快到哪去吧。
外键必须要用innodb，速度较慢，用myisam速度更快，外键可以用关联查询解决
外键和例如范式这种东西只应该存在于教科书上面。禁止外键和反范式才是应该做的。外键和查询效率并没有联系。作用仅仅是建立数据的联系，那么，数据的联系为何不通过逻辑来约束呢。
有些公司建表不加外键
工作以来从没加过外键 :D 依赖多了反而麻烦，性能的话应该没影响吧，从来没看见过添加外键来提升效率的文档。 我是菜鸟，别喷我，哈哈，伤不起。路过路过
外健主要是保持数据的完整性和一致性。譬如用户表和用户订单表，如果没有外健关联，你是可以插入订单表的。但是这个订单表属于那个用户，你怎么知道。那这样的数据就成孤魂野鬼了。有了外健关联。你在插入的时候必须要求用户表中有相关用户才能插入，同里你在删除用户表的数据时，如果订单表有引用的话，你是无法删除的。这就保证了数据的一致性和完整性。
外键约束主要是在数据库层面上保证数据的一致性，对性能提升没什么帮助，因为插入和更新数据需要检查外键，理论上性能会有所下降，在oralce中外键会增加主从表中主表锁定的竞争，对性能是负面的影响。
实际的项目，不建议使用外键，一方面是降低开发的复杂度（有外键的话主从表类的操作必须先操作主表），另外是有外键在处理数据的时候非常麻烦。
在应用层面做数据的一致性检查，本来就是一个正常的功能需求，如学生选课的场景，课程肯定不是输入的，而是通过下拉或查找等方式从系统中进行选取，就能够保证是合法的课程ID，因此就不需要靠数据库的外键来检查了。
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
外键是约束，既然是约束肯定就会增加额外的开销。例如书中常见的示例，学生选课系统，学生表和课程表，中间肯定会有一个学生课程关联表。如果添加了外键约束，你在删除某个课程的时候，肯定会先检查这个课程是不是有学生已经选了，不然你删除后学生选的那个课程会找不到而引发错误。
不明白为什么要反模式，省略外键约束能使得数据库设计更加简单、灵活，或者执行更加高效，但你还是不得不在其他方面付出相应的代价，必须增加额外的代码来手动维护引用完整性。本来数据库一个约束键可以解决的，现在还要写一段代码去维护。而且手动写代码维护判断，也是一种约束，也会有性能损耗，只不过是在逻辑层面，和数据库相比不会快到哪去吧。
外键必须要用innodb，速度较慢，用myisam速度更快，外键可以用关联查询解决
外键和例如范式这种东西只应该存在于教科书上面。禁止外键和反范式才是应该做的。外键和查询效率并没有联系。作用仅仅是建立数据的联系，那么，数据的联系为何不通过逻辑来约束呢。
有些公司建表不加外键
工作以来从没加过外键 :D 依赖多了反而麻烦，性能的话应该没影响吧，从来没看见过添加外键来提升效率的文档。 我是菜鸟，别喷我，哈哈，伤不起。路过路过
外健主要是保持数据的完整性和一致性。譬如用户表和用户订单表，如果没有外健关联，你是可以插入订单表的。但是这个订单表属于那个用户，你怎么知道。那这样的数据就成孤魂野鬼了。有了外健关联。你在插入的时候必须要求用户表中有相关用户才能插入，同里你在删除用户表的数据时，如果订单表有引用的话，你是无法删除的。这就保证了数据的一致性和完整性。
外键约束主要是在数据库层面上保证数据的一致性，对性能提升没什么帮助，因为插入和更新数据需要检查外键，理论上性能会有所下降，在oralce中外键会增加主从表中主表锁定的竞争，对性能是负面的影响。
实际的项目，不建议使用外键，一方面是降低开发的复杂度（有外键的话主从表类的操作必须先操作主表），另外是有外键在处理数据的时候非常麻烦。
在应用层面做数据的一致性检查，本来就是一个正常的功能需求，如学生选课的场景，课程肯定不是输入的，而是通过下拉或查找等方式从系统中进行选取，就能够保证是合法的课程ID，因此就不需要靠数据库的外键来检查了。