概念：
为了保证数据的完整性和一致性，MySQL提供了约束这个属性。约束分为表级约束和列级约束，如果约束只是针对某一个字段来说，则称之为列级约束，如果针对两个或者两个以上的，则称之为表级约束。列级约束既可以在列定义时声明，也可以在列定义后声明，而表级约束只能在列定义后声明。
约束类型包括以下几种：
NOT NULL （非空约束）
PRIMARY KEY （主键约束）
UNIQUE KEY （唯一约束）
DEFAULT （默认约束）
FOREIGN KEY （外键约束）
场景：
在操作数据表时，为了避免插入重复的数据，可以在字段后面添加 AUTO_INCREMENT（自动编号） 属性来保证记录的唯一性，并且该字段必须为整型或者字符型，若使用字符型，小数必须为 0 。
该属性如下特点：
⑴ 赋予自动编号属性的字段必须定义为主键
⑵ 在默认情况下，起始值为1，每次递增加1
案例：
创建一张 tb_test2 数据表，并且给 id 字段赋予 AUTO_INCREMENT 属性，系统报错，根据信息可以看出，字段 id 必须设置为主键。接下来我们来了解一下主键约束和其他约束。（非空约束在上一文结尾已提及）
1、主键约束 （PRIMARY KEY）
特点：
⑴ 每张数据表只能存在一个主键
⑵ 主键可以保证记录的唯一性
⑶ 主键自动默认为 NOT NULL
案例：
以刚才创建的表为例，重新创建数据表，在 id 后添加 PRIMARY KEY 属性表示该字段为主键。
接着查看数据表的结构：
可以发现，字段 id 不为 NULL 符合 AUTO_INCREMENT 属性特点，key 的值为 PRI，说明该字段为主键，而 username 在创建时已经指定为 NOT NULL 。当我们依次插入数据时，对应的id 会自动增长。
案例：（数据表的记录操作会在后续的文章提及）
依次插入三条记录，并查看所有记录，数据表的 id 自动递增。
注： AUTO_INCREMENT 必须和 PRIMARY KEY 一起使用，而 PRIMARY KEY 不一定和
AUTO_INCREMENT 一起使用。
案例：
当我们创建数据表并没有给主键 id 赋予 AUTO_INCREMENT 时，系统提示创建成功，此时的 id 不能为空，查询表结构可以看出 Extra 字段没有 auto_increment 属性。我们插入一些记录来验证一下：
在插入记录时，分别对 id 和 username 字段进行赋值，但是不允许插入两条相同的记录：
当我们插入相同 id 的记录时，系统报错，提示表已存在该记录。
在一张数据表中，除了主键约束外，为了保证记录的唯一性，MySQL 提供了另一种约束，
就是唯一约束。
2、唯一约束 （UNIQUE KEY）
特点：
⑴ 唯一约束可以保证记录的唯一性
⑵ 唯一约束的字段可以为空值（NULL）
⑶ 每张数据表可以存在多个唯一约束
当然了，对于指定唯一约束的字段来说，如果插入的多条记录都为空，表里也只存在一条空记录，保证唯一性。
案例：
创建表 tb_test4 ，字段 id 为主键且自动增长，username 为字符型且唯一约束。
我们插入记录验证一下：
插入一条记录提示成功。
重新插入一条相同的记录，系统报错，不能重复添加，说明 username 被赋予唯一约束，只能插入一条记录。
3、默认约束 （DEFAULT）
特点：
当插入记录时，如果没有明确为字段赋值，系统自动赋予默认值
案例：
创建数据表 tb_test5 并查看表结构，其中，sex 字段含有三个值，分别对应男、女、保密三种性别，且默认值为 3 。
插入一条只给 username 赋值的记录时 ，查询记录，可以发现，字段 sex 的记录值为 3 ，也就是默认值。
4、外键约束（FOREIGN KEY）
特点：
⑴ 保持数据一致性，完整性
⑵ 实现一对一或一对多关系
要求：
⑴ 父表（字表所参照的表）和子表（具有外键列的表）必须使用相同的存储引擎，而且禁止使用临时表。
⑵ 数据表的数据引擎只能为 InnoDB。
⑶ 外键列和参照列必须具有相同的数据类型。其中数字的长度或是否有符号位必须相同；
而字符的长度则可以不同。
⑷ 外键列和参照列必须创建索引。如果不存在索引的话，MySQL将自动创建索引。
我们通过以上要求要创建表并赋予外键约束。
案例：
首先查看数据库的默认存储引擎：
由返回结果看出，MySQL默认存储引擎为 InnoDB 。
现在我们创建两张表，并对指定的字段赋予相同的数据类型：
创建一张省份表并查看该表的引擎：
由图可以看出，存储引擎是 InnoDB 满足要求。
再创建一张用户表，含有用户id，用户名username ，和用户所在省份的外键 pid ，此时创建失败，因为外键 pid 的数据类型和父表中的 id 数据类型不一致导致无法创建，同样，如果外键 pid 是否有符号与父表的主键 id 不一致，也是无法创建成功的。
其中，约束外键的语法结构为：
FOREIGN KEY （外键 id）REFERENCES 父表名称 （父表所参照的 id）。
由图可以得出，外键 pid 满足数据类型和是否有符号和父表主键 id 一致，所以该表创建成功。注：外键列（pid）和参照列（id）必须创建索引。
我们来看看两张表是否有创建索引：
由图可以看出，数据表 tb_province 的参照列 id 已经创建了主键索引。
而对于数据表 tb_users ,可以发现存在两个索引，一个是主键索引 id，另一个 pid 系统已经自动创建了索引。
通过查看所该表的创建命令，可以看出系统给 pid 自动创建了索引（ KEY 'pid'），同时在
CONSTRAINT 'tb_users_ibfk_1' FOREIGN KEY ('pid') 可以得出 pid 为外键约束。
在我们创建外键约束的时候，可以添加一些外键约束的参照操作，有如下几种：
⑴ CASCADE：父表删除或更新行时，同时自动更新或更新子表匹配的行
⑵ SET NULL：从父表删除或更新行，并设置子表中的外键列为 NULL 。如果使用该选项，必须保证子表列没有指定 NOT NULL
⑶ RESTRICT：拒绝对父表的删除或更新操作
⑷ NO ACTION：标准 MySQL 的关键字，在 MySQL 中与 RESTRICT 相同
在更新表的时候，可以通过以上选项来设置子表是否进行相应的操作。
案例：
我们创建一张 tb_users1 数据表，给 pid 设置为外键约束，同时在删除的时候，设置 CASCADE 选项。
接下来通过插入信息来验证一下。由于子表（tb_users1）参照父表（tb_province），为了保证子表有参照数据，必须先在父表里插入记录。
对父表（tb_province）依次插入三条记录，并查询所有记录。
对子表（tb_user1）依次插入三条记录，并查询所有数据。
现在两张表都存在记录，我们先通过删除记录来验证一下，CASCADE 选项。
首先删除父表（tb_province）中 id 为 2 的记录：
查询 tb_province 所有记录：
可以看出，原先记录 id = 2 已经被删除了。
我们再来查询一下子表中 pid = 3 的记录是否还存在：
由图可以得知，pid = 2 的所有记录已经被删除了。
这就是 CASCADE 所起的作用，父表删除记录同时删除子表所相关的记录，同理更新的操作也会影响子表的记录。
在实际开发中，我们很少使用物理的外键约束，一般使用逻辑的外键约束，因为物理外键约束只有在 InnoDB 引擎下才得以支持，而物理外键可以通过在两张表中存在某种结构来定义约束，而不使用 FORENGIEN KEY 这个关键词来定义。
总结：
列级约束使用比较多，表级约束很少使用，在以上几种约束中，NOT NULL 约束，DEFAULT 约束这两种约束不存在表级约束，它们只有列级约束，而对于其他的三种，PRIMARY KEY 约束，UNIQUE 约束，FORENGIEN KEY 约束，它们都可以存在表级和列级约束。
约束分为以下几种：
⑴ 功能
① NOT NULL （非空约束）
② PRIMARY KEY（主键约束）
③ UNIQUE KEY（唯一约束）
④ DEFAULT（默认约束）
⑤ FROEIGN KEY（外键约束）
⑵ 数据列的数目
① 表级约束
② 列级约束
以上为本人的一些学习笔记，如有出错欢迎指正，陆续更新！！！
