原文: https://www.itcodemonkey.com/article/11317.html

外键约束是一种约束，这个约束的存在，会保证表间数据的关系“始终完整”。因此，外键约束的存在，并非全然没有优点。

比如使用外键，可以


	
保证数据的完整性和一致性
	
	

	
级联操作方便
	
	

	
将数据完整性判断托付给了数据库完成，减少了程序的代码量
	
然而，鱼和熊掌不可兼得。外键是能够保证数据的完整性，但是会给系统带来很多缺陷。正是因为这些缺陷，才导致我们不推荐使用外键，具体如下

性能问题

假设一张表名为user_tb。那么这张表里有两个外键字段，指向两张表。那么，每次往user_tb表里插入数据，就必须往两个外键对应的表里查询是否有对应数据。如果交由程序控制，这种查询过程就可以控制在我们手里，可以省略一些不必要的查询过程。但是如果由数据库控制，则是必须要去这两张表里判断。

并发问题

在使用外键的情况下，每次修改数据都需要去另外一个表检查数据,需要获取额外的锁。若是在高并发大流量事务场景，使用外键更容易造成死锁。

扩展性问题

这里主要是分为两点


	
做平台迁移方便，比如你从Mysql迁移到Oracle，像触发器、外键这种东西，都可以利用框架本身的特性来实现，而不用依赖于数据库本身的特性，做迁移更加方便。
	
	

	
分库分表方便，在水平拆分和分库的情况下，外键是无法生效的。将数据间关系的维护，放入应用程序中，为将来的分库分表省去很多的麻烦。
	
技术问题

使用外键，其实将应用程序应该执行的判断逻辑转移到了数据库上。那么这意味着一点，数据库的性能开销变大了，那么这就对DBA的要求就更高了。很多中小型公司由于资金问题，并没有聘用专业的DBA，因此他们会选择不用外键，降低数据库的消耗。


相反的，如果该约束逻辑在应用程序中，发现应用服务器性能不够，可以加机器，做水平扩展。如果是在数据库服务器上，数据库服务器会成为性能瓶颈，做水平扩展比较困难。

	

我的经验告诉我，很多数据库(大多数我曾经使用的)不包含外键时并不总是一件坏事。在这篇文章中，我想把重点放在为什么的原因上。
为什么这是一个问题？
1.潜在的数据完整性问题，
缺少外键明显问题是数据库不能强制进行引用完整性检查，如果在高一层没有正确处理，则可能会导致数据不一致(子行没有相应父行)。
2.表格关系不清晰
数据库中缺少外键的另一个不太明显的负面影响是，不了解该模式的人很难找到正确的表并找出表关系。这可能会导致严重的数据库查询和报告问题。
为什么数据库可以没有外键？
让我们来看看数据库可以没有外键的原因。首先一个简短的免责声明(因为文章引发了一些关于LinkedIn群体的争议)：
下面的理由绝不鼓励不要在数据库中使用外键约束。这仅仅是我在各种渠道(主要是互联网论坛)都能找到的许多开发人员、架构师为什么不使用它们的理由。
我个人(和许多其他经验丰富的数据库专家)建议在任何可能的地方使用它们(不会导致更多的问题)。
1.性能
在表上拥有活动的外键可以提高数据质量，但会影响插入、更新和删除操作的性能。在这些任务之前，数据库需要检查它是否违反数据完整性。这就是为什么一些架构师和DBA完全放弃外键的原因。
数据仓库和分析数据库尤其如此，这些数据仓库和分析数据库不以交易方式(一次一行)处理数据，而是批量处理数据。性能是数据仓库和商业智能的一切。
2.传统数据
许多数据库在设计时需要存储来自旧数据库和遗留数据，这些数据可能对数据质量和完整性没有那么严格。为了能够容纳旧的脏数据，架构师可以选择a)清理和转换遗留数据(昂贵的练习)，或者b)放弃在数据库级别上强制执行参照完整性。一些打包的ERP和CRM应用程序也使用这种方法。
3.全表重新加载
一些数据库，如数据仓库，分段或接口数据库，需要经常从外部重新加载数据。这会导致重新加载时数据不一致(在父表为空的情况下，子表可能已满载)。这可以通过在重新加载时禁用外键来绕过。
然而，这引入了额外的逻辑和复杂性以及另一个失败点。如上所述，对性能有负面影响。通常，成本大于收益，开发人员不用担心外键。
4.更高层次的框架
一些应用程序使用编程框架，在物理数据库之上创建另一个逻辑层。开发人员不使用插入或更新语句来修改数据，而使用API或者框架在后台执行所有操作。ORM(对象关系映射)框架或Ruby on Rails框架就是这种情况。
这些工具负责参照完整性，并与RDBMS一起创建更高级别的数据库引擎。这些框架可以自己创建数据库表，而不总是创建外键。使用这些工具的开发人员很少会干扰自动生成的模式，并且不需要外键。
5.跨数据库关系
这可能不是数据库没有外键的正确理由，一些数据库跨越更多的物理数据库甚至引擎，并且在技术上可能不能创建跨越数据库的它不能在同一台服务器上的两个数据库上创建key。
SQL Server就是一个很好的例子 - 它不能在同一台服务器上的两个数据库上创建key。而且这种架构在大型系统中很常见。
6.数据库平台不可知论者
类似于前一个，一些应用程序被设计为数据库平台(DBMS)不可知的，并能够在Oracle，SQL Server，DB / 2或Sybase等各种数据库上工作。
这是我读过的有关PeopleSoft(目前由Oracle拥有)的内容。设计人员不想绑定到任何特定的平台，并将所有逻辑推送到应用程序层，尽可能清楚地离开数据库层。
7.对更改开放
我与Oracle一直保持紧密联系，我听说过另一个关于其应用程序的故事，这是Oracle自己的产品 - Oracle电子商务套件 - 就是它被设计成尽可能定制。
Oracle提供了坚实的基础，使实施团队具有弹性，可以尽可能多地决定设计。至少这是他们所说的。也许这个原因和以前一样，或者是下一个原因：
8.懒惰的架构师
在创建数据库时，如果要存储数据，则需要创建一些表和列。这是最低限度。但是，您不必创建保持数据一致性的结构，如主键，唯一键，外键或约束。
这需要一些努力，但是却没有带来直接的好处。一些架构师和数据库管理员只是忽略了这一部分。
9.保持模型的秘密
也许这是一个很遥远的问题，但也许有时候是因为人们不希望别人知道太多太容易。一般来说，人们希望被需要和不可替代。一个完美的自我解释的设计可能会使他们过时。但这只是我的理论。
来源:www.jdon.com/49188
全文完
推荐阅读：
java | 什么是动态代理
恕我直言，你可能连百度都不会用
国庆抢不到票？可以试试这两个工具
Spring 复盘(一) | IOC
Spring 复盘(二) | AOP
Spring 复盘(三) | Bean 的生命周期
SpringBoot | 启动原理
SpringBoot | 自动配置原理
Spring MVC 复盘 | 工作原理及配置详解
如果喜欢本文，欢迎转发。记得点“在看”，最底部小卡片支持下。还有，把公号加星标，别嫌麻烦，新文章才不会漏。

数据库主键是指表中一个列或列的组合，其值能唯一地标识表中的每一行。这样的一列或多列称为表的主键，通过它可强制表的实体完整性。一个表只能有一个 PRIMARY KEY 约束，而且 PRIMARY KEY 约束中的列不能接受空值。

 主键具有的特点：唯一性、非空性。


思考：主键带来了什么样的优点和缺点？


外键也叫FOREIGN KEY，是用于将两个表链接在一起的键。

FOREIGN KEY是一个表中的一个字段（或字段集合），它引用另一个表中的PRIMARY KEY。

包含外键的表称为子表，包含候选键的表称为引用表或父表。

请看以下两个表：

Person表

PersonID
			
LastName
			
FirstName
			
Age
		
1
			
Hansen
			
Ola
			
30
		
2
			
Svendson
			
Tove
			
23
		
3
			
Pettersen
			
Kari
			
20
		
Orders表

OrderID
			
OrderNumber
			
PersonID
		
1
			
77895
			
3
		
2
			
44678
			
3
		
3
			
22456
			
2
		
4
			
24562
			
1
		
Orders表中的PersonID列指向Persons表中的PersonID列。

Persons表中的PersonID列是Persons表中的PRIMARY KEY。

Orders表中的PersonID列是Orders表中的FOREIGN KEY。

外键带来的好处主要是，保证数据的完整性和一致性，主要目的是控制存储在外键表中的数据。同时支持关联查询。FOREIGN KEY约束用于防止会破坏表之间链接的操作

关于外键的使用存在一些争议，因为它在确保两个表之间的关系的时候又带来很多限制，很多工程师认为应该在代码逻辑里控制两个表的关系，而不在数据库表之间定义这样的关系。同时，外键对数据的插入删除等都会带来影响，因为表与表之间存在关联，因此各种操作都会变慢，因此在定义外键之前应该尽量考虑好数据的量，以及数据的读写频率等等。

个人从目前的实际经验出发也不是特别喜欢太多的外键关系存在。尽量子代码曾通过逻辑控制数据之间的关系可能确实是更好的做法。在使用的时候应该结合实际情况进行抉择。

 

 

 

目录
1. 非空约束
2. 唯一约束
3. 主键约束
自动增长
4. 外键约束
级联操作

首先我们来想象一下，前几篇文章在我们操作数据库的过程中，自由度是很高的，想给哪个赋值就给哪个赋值，但是这样子，就会造成我们所创建的数据库数据不完整，例如我创建一个学生信息表，你可能添加时候忘了添加学号、忘了添加名字、忘了添加成绩等等，因此我们就需要利用约束来创建我们的表，对表中的数据进行限定，保证数据的正确性、有效性和完整性
1. 非空约束
非空约束顾名思义就是约束它不能为空，也就是必填项，其所使用的关键字是NOT NULL，关于该非空约束有三种操作，为方便讲解，以下的语句均是对bound1表中的NAME项进行操作：

创建表时添加非空约束：CREATE TABLE bound1(id INT,NAME VARCHAR(8) NOT NULL);
创建常规表后再添加非空约束：ALTER TABLE bound1 MODIFY NAME VARCHAR(8) NOT NULL;
删除非空约束：ALTER TABLE bound1 MODIFY NAME VARCHAR(8);

下面来操作一下，这里先新建一个表，添加一个数据看看
CREATE TABLE bound1(id INT,NAME VARCHAR(8) NOT NULL);
INSERT INTO bound1(id,NAME) VALUES(1,"amy");
SELECT * FROM bound1;



ok，这项数据是可以成功添加的，那么下面我们来添加一下只有id的项看看是否能够成功
INSERT INTO bound1(id) VALUES(2);



显然是不行的，我们可以把非空约束删掉再试一次
ALTER TABLE bound1 MODIFY NAME VARCHAR(8);
INSERT INTO bound1(id) VALUES(2);
SELECT * FROM bound1;



去掉非空约束后便可以正常添加了，如果，此时你又想把非空约束加回去行不行呢？我们来试试
ALTER TABLE bound1 MODIFY NAME VARCHAR(8) NOT NULL;



咦，怎么不行？语句错了吗？其实没有，出现该问题的原因是你的表中的NAME项已经有一个NULL值存在，不符合非空约束，因此需要把该项删除才能成功添加非空约束
换言之，添加约束的前提是该表中对应的数据需要符合该约束，随后介绍的约束也是如此
2. 唯一约束
唯一约束，同样也是字面意思，用于约束该项的值不与已存在的值重复，更贴近生活的例子是学生的学号、自然人的身份证号、机动车号牌等，同样的，该约束也是有三种操作，以下的语句均是对bound2表中的id项进行操作：

创建表时添加唯一约束：CREATE TABLE bound2(id INT UNIQUE,NAME VARCHAR(8));
创建常规表后再添加唯一约束：ALTER TABLE bound2 MODIFY id INT UNIQUE;
删除唯一约束：ALTER TABLE bound2 DROP INDEX id;

看到删除唯一约束时可能有同学会参考上一节中的删除非空约束想用MODIFY进行修改，但其实删除唯一约束用MODIFY是不行的，必须使用这里所介绍的DROP
国际惯例，还是来操作一下，这里先新建一个表，添加一个数据看看
CREATE TABLE bound2(id INT UNIQUE,NAME VARCHAR(8));
INSERT INTO bound2(id,NAME) VALUES(1,"amy");
SELECT * FROM bound2;



下面再给他添加一个重复的id看看可不可以
INSERT INTO bound2(id,NAME) VALUES(1,"john");



结果你肯定也猜到是不行的，另外约束的删除和新增的效果和步骤跟上一节一样，这里不再重复演示了
3. 主键约束
什么叫主键约束呢？主键约束的精粹在于“主”，正所谓一山不能容二虎，既然是“主”，那就必须是“唯一”的，另外，“主”的位置也是不可或缺的，因此也必须是“非空”的，那么综上所述，主键约束的含义就是非空且唯一，同样的，该约束也是有三种操作，以下的语句均是对bound3表中的id项进行操作：

创建表时添加主键约束：CREATE TABLE bound3(id INT PRIMARY KEY,NAME VARCHAR(8));
创建常规表后再添加主键约束：ALTER TABLE bound3 MODIFY id INT PRIMARY KEY;
删除主键约束：

ALTER TABLE bound3 DROP PRIMARY KEY;-- 去除主键约束后其还是非空约束
ALTER TABLE bound3 MODIFY id INT;-- 因此需要再次去除非空约束

是不是感觉这个删除又有点特别？对，就是这么特别，它需要执行两条语句才能把主键约束的项变成普通项，若只执行第一条语句它只会把主键约束变成非空约束
好啦，下面来操作一下吧，这里先新建一个表，添加一个数据看看
CREATE TABLE bound3(id INT PRIMARY KEY,NAME VARCHAR(8));
INSERT INTO bound3(id,NAME) VALUES(1,"amy");
SELECT * FROM bound3;



没毛病，那下面再来添加一个重复id，一个空id的项看看是否能够成功
INSERT INTO bound3(id,NAME) VALUES(1,"john");


INSERT INTO bound3(NAME) VALUES("kc");



显然都是不行的，一个提示为不能重复，一个提示为不能为空，下面再来体验一下这个特别的删除，这里先执行前面介绍的第一条删除语句
ALTER TABLE bound3 DROP PRIMARY KEY;

然后添加一个重复id的项看看
INSERT INTO bound3(id,NAME) VALUES(1,"john");
SELECT * FROM bound3;



显然添加成功了，下面再来看看添加一个空id项
INSERT INTO bound3(NAME) VALUES("kc");



这报错就来了，因此这就是我前面所说的，第一条删除语句只把主键约束变成了非空约束，若需要变成普通项，则还需要执行第二条语句
ALTER TABLE bound3 MODIFY id INT;

再添加那个空id数据试试看
INSERT INTO bound3(NAME) VALUES("kc");
SELECT * FROM bound3;



这时候就可以成功添加了，同样的，若此时想重新添加主键约束，必须要把表中重复的与空的项删除才可以
自动增长
自动增长是针对主键约束中为数值类型的列服务的，有什么情况下需要用到自动增长呢？例如学生的学号，我们都知道学号是有规律增长的，因此我们可以使用AUTO_INCREMENT关键字实现该值的自动增长，该操作同样有三种，以下的语句均是对bound4表中的id项进行操作：

创建表时添加主键约束并且添加自动增长：CREATE TABLE bound4(id INT PRIMARY KEY AUTO_INCREMENT,NAME VARCHAR(8));
创建主键约束表后再添加自动增长：ALTER TABLE bound4 MODIFY id INT AUTO_INCREMENT;
删除自动增长：ALTER TABLE bound4 MODIFY id INT;

注意，删除自动增长语句仅取消了自动增长，其仍然是主键约束，接下来还是演示时间，这里先新建一个表，添加一个数据看看
CREATE TABLE bound4(id INT PRIMARY KEY AUTO_INCREMENT,NAME VARCHAR(8));
INSERT INTO bound4(id,NAME) VALUES(1,"amy");
SELECT * FROM bound4;



下面来添加一个空id项看看能不能实现自动增长
INSERT INTO bound4(NAME) VALUES("kc");
SELECT * FROM bound4;



显然我们的id没有赋值，但它可以实现自动增长赋值，下面我来接连添加两条数据，一个给id赋值，一个不给id赋值，那么你感觉不给id赋值的会跟着哪个数值实现自动增长呢？
INSERT INTO bound4(id,NAME) VALUES(5,"john");
INSERT INTO bound4(NAME) VALUES("jam");

你觉得自动增长的一项是6还是跟回之前的数字是3呢？下面来揭开谜底



显然是跟着最后的一项数值实现自动增长的
4. 外键约束
外键约束就没有前面几项约束理解起来那么简单了，但也不要怕，还是挺容易明白的，首先我们来看一个数据表



你会发现，这里研发部都在广州，销售部都在深圳，那么两项都写出来，显得这个数据库都有点繁杂，即有冗余的部分，有没有办法可以解决呢？有的，我们可以把它分开两个表，一个储存人员信息与部门代号，一个储存部门的详细信息，同时也要让他们之间产生关联
为什么要产生关联呢？例如举一个简单的例子，假如我公司只有两个部门，代号分别是1和2，但是你在添加人员信息时候写错了部门代号为5，这样子就会添加了错误的数据，那么产生关联后有什么作用呢？假如你让两个表产生了关联，那么当你添加错误代号时候就会报错提醒你不能成功添加
总的来说，外键约束就是让表与表之间产生关系，从而保证数据的正确性，同样的，其相关操作也是三种：

创建表时添加外键约束：

CREATE TABLE 表名(列名1 数据类型1, 列名2 数据类型2, ... , 列名n 数据类型n, CONSTRAINT 外键名称 FOREIGN KEY(副表列名) REFERENCES 主表名(主表列名));
创建普通表后再添加外键约束：

ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY(副表列名) REFERENCES 主表名(主表列名);
删除外键约束：

ALTER TABLE 表名 DROP FOREIGN KEY 外键名称;

注意：

要分清楚上面所提到的主表和副表，副一定是受到主的限制的，副表主表之间也是如此，还是以员工表和部门表为例子，一定是先有部门才有员工归属到这个部门，因此，员工表是副表，部门表是主表，再直白一点说，以上三条语句的都是副表上进行操作的
语句中的外键名称，其实就是你给这个副表与主表的关系起个名，你喜欢起什么名字都行，记住就好

搞清楚之后，我们来新建一个，bound5是部门表（主表），bound6是员工表（副表），添加一下数据
CREATE TABLE bound5(id INT PRIMARY KEY AUTO_INCREMENT,department VARCHAR(8),city VARCHAR(8));
CREATE TABLE bound6(id INT PRIMARY KEY AUTO_INCREMENT,NAME VARCHAR(8),department INT,CONSTRAINT 5and6 FOREIGN KEY (department) REFERENCES bound5(id));
INSERT INTO bound5(department,city) VALUES("研发部","广州"),("销售部","深圳");
INSERT INTO bound6(NAME,department) VALUES("张三",1),("李四",2),("王五",1),("赵六",1),("田七",2),("何八",2);

然后分别来看看两个表





对了，教你一种方法看看有没有成功添加外键约束





好啦，那我们前面所说的约束作用怎么体现出来呢？注意看，部门表中只有两个部门，编号是1和2，那么下面我们往员工表上添加两个部门编号为5的员工信息看看能不能成功
INSERT INTO bound6(NAME,department) VALUES("吴九",5),("陈十",5);



显然是不可以的，那么如果我在部门表加上编号为5的部门之后再试试呢？
INSERT INTO bound5(id,department,city) VALUES(5,"人事部","上海");


INSERT INTO bound6(NAME,department) VALUES("吴九",5),("陈十",5);



毫无意外地添加成功了，那这时候集团老板觉得这个部门编号太跳脱了，应该改回3，可不可以呢？
UPDATE bound5 SET id=3 WHERE id=5; 



对不起，不可以，这是为啥呢？因为关联了呀，要是你改了编号，我那些写着部门编号是5的员工不就不属于任何部门了吗？那我裁掉这个部门总行了吧，试试看
DELETE FROM bound5 WHERE id=5;



怎么还是不行？同样道理嘛，部门裁掉之后员工也是无家可归了呀，不过别担心，还有高级操作可以让两个表产生联动，下面来看看级联操作
级联操作
级联操作，说白了就是来解决刚才说到的两个痛点的，级联操作可以实现同步更新或同步删除，它的语法也很简单，ON UPDATE CASCADE表示同步更新，ON DELETE CASCADE表示同步删除，需要哪个就写哪个，下面来看一下：

ALTER TABLE 表名 ADD CONSTRAINT 外键名称 FOREIGN KEY(副表列名) REFERENCES 主表名(主表列名) ON UPDATE CASCADE ON DELETE CASCADE;
让我们来添加级联操作再看看刚刚的更改部门编号能否成功
ALTER TABLE bound6 ADD CONSTRAINT 5and6 FOREIGN KEY (department) REFERENCES bound5(id) ON UPDATE CASCADE ON DELETE CASCADE;
UPDATE bound5 SET id=3 WHERE id=5;





显然更改了部门表后员工表也自动同步更改了，那么删除操作是怎么样的呢？再来试试看
DELETE FROM bound5 WHERE id=3;





显然部门表中的部门被删除了，员工表中的相关员工也被自动删除了，即使级联操作可以给我们带来便利，但是在不是非常确定表表之间产生的连带关系的时候，我们还是要谨慎操作这一特性
至此，约束的相关内容也全部介绍完啦，下篇文章中将会介绍多表关系