Mysql外键知识点整理

基础知识：外键约束（FOREIGN KEY）

外键约束定义在具有父子关系的子表中，外键约束使得子表中的列对应父表的主键列，用以维护数据库的完整性。不过出于性能和后期的业务系统的扩展的考虑，很多时候，外键约束仅出现在数据库的设计中，实际会放在业务程序中进行处理。外键约束注意以下几点：
　　1、外键约束的子表中的列和对应父表中的列数据类型必须相同，列名可以不同
　　2、对应的父表列必须存在主键约束（PRIMARY KEY）或唯一约束（UNIQUE）
　　3、外键约束列允许NULL值，对应的行就成了孤行了
其实很多时候不使用外键，很多人认为会让删除操作比较麻烦，比如要删除父表中的某条数据，但某个子表中又有对该条数据的引用，这时就会导致删除失败。我们有两种方式来优化这种场景：

第一种方式简单粗暴，删除的时候，级联删除掉子表中的所有匹配行，在创建外键时，通过 on delete cascade 子句指定该外键列可级联删除：

SQL> alter table emp add constraint emp_deptno_fk foreign key(deptno) references dept (deptno) on delete cascade;

第二种方式，删除父表中的对应行，会将对应子表中的所有匹配行的外键约束列置为NULL，通过 on delete set null 子句实施：

SQL> alter table emp add constraint emp_deptno_fk foreign key(deptno) references dept(deptno) on delete set null;

实际上，外键约束列和对应的父表列可以在同一张表中，常见的就是表的业务逻辑含义是一棵树，最简单的例子如下（id为主键id，fid为父id，fid存储对id的引用），这种结构的表根据业务要求可通过Oracle的递归查询来获取这种层级关系

来自：Oracle约束(Constraint)详解

实际开发中，是否会在数据库表中设置外键？

设计数据库时是否采用外键取决于业务应用场景，以及开发成本，也就是说对于这个问题并没有绝对的答案。 应用场景的比较：

互联网行业应用不推荐使用外键：
用户量大，并发度高，为此数据库服务器很容易成为性能瓶颈，尤其受IO能力限制，且不能轻易地水平扩展；若是把数据一致性的控制放到事务中，也即让应用服务器承担此部分的压力，而引用服务器一般都是可以做到轻松地水平的伸缩；

传统行业（软件使用人数可控）的可以使用外键。 外键的性能问题
1.数据库需要维护外键的内部管理；
2.外键等于把数据的一致性事务实现，全部交给数据库服务器完成；
3.有了外键，当做一些涉及外键字段的增，删，更新操作之后，需要触发相关操作去检查，而不得不消耗资源；
4.外键还会因为需要请求对其他表内部加锁而容易出现死锁情况； 历史背景： 数据库的诸多设计，帐号，权限，约束，触发器，都是为 C/S 结构设计的，是以 C 端不可信做为假设前提的。B/S 模式安全边界前移到 web
服务层，应用与数据库之间是可信的，应用自行完成这些功能更加灵活。

来自：实际开发中，是否会在数据库表中设置外键？