Mysql中约束详解
约束定义 约束是用来限定表中数据准确性、完整性、一致性、联动性的一套规则。在Mysql中,约束保存在information_schema数据库的table_constraints中,可以通过该表查询约束信息。如下图: 常见的约束 not null not null为非空约束,指定某一行的值不能为nul
约束定义
约束是用来限定表中数据准确性、完整性、一致性、联动性的一套规则。在Mysql中,约束保存在information_schema数据库的table_constraints中,可以通过该表查询约束信息。如下图:
常见的约束
not null
not null为非空约束,指定某一行的值不能为null。
我在t2表中添加了一列id3,设置varchar类型,not null约束。当执行插入INSERT INTO t2 (id1,id2) VALUES(1,2);
操作的时候,出现了警告,但是插入数据成功。
很显示,没有达到我们预期的效果,不是说varchar/char/test等默认的是null吗?既然我没有赋值,针对默认的值,应该插入不成功啊?但是查看数据如下:
于是我想,那么我将id3设置为一个null试试,结果如下图,很显然Mysql对Not NULL 约束,是建立在判断插入语句里面赋的值是不是null。如果限制为not null的列在插入语句没有赋值null,则允许插入,否则禁止插入。(如果默认值NULL,且该列没出现在插入语句,则会产生一个警告信息,但是仍然能插入Okey)
备注:所有的类型的值都可以是null,包括int、float、dateTime等数据类型 空字符串(”)是不等于null,0也不等于null 。
unique
unique代表唯一约束。唯一约束是指定table的列或列组合不能重复,保证数据的唯一性。虽然唯一约束不允许出现重复的值,但是可以为多个null,同一个表可以有多个唯一约束,多个列组合的约束。在创建唯一约束的时候,如果不给唯一约束名称,就默认和列名相同。 MySQL会给唯一约束的列上默认创建一个唯一索引;
添加约束 ALTER TABLE t2 ADD CONSTRAINT uq_id2_id3 UNIQUE(id2,id3) ;
可以看到Mysql会自动添加一个唯一索引。
有没有感觉,觉得唯一索引和唯一约束貌似就是一种东东。其实,两者还是有区别的。首先从大的概念来说,索引是一个树用来快速搜索的,约束是一个逻辑限制。唯一约束是通过唯一索引实现的,换句说,唯一索引是实现唯一约束的基础。所以,会发生这种情况:建唯一约束,会自动建唯一索引,但建唯一索引,不会自动创建唯一约束。但创建了唯一索引,会产生和唯一约束相同的效果,即不能插入重复值(但唯一索引和唯一约束允许出现多个空值),否则会报错。
当建立唯一索引后,表的结果图下图
连续执行INSERT INTO t2 (id1,id2,id3) VALUES(1,3,NULL);
插入成功。说明对于,当为空值时候,唯一索引是不进行判断唯一性的。
primary key
主键约束相当于唯一约束+非空约束的组合,主键约束列不允许重复,也不允许出现空值;如果的多列组合的主键约束, 那么这些列都不允许为空值,并且组合的值不允许重复。 每个表最多只允许一个主键,建立主键约束可以在列级别创建,也可以在表级别上创建。
MySQL的主键名总是PRIMARY, 当创建主键约束时,系统默认会在所在的列和列组合上建立对应的唯一索引。
foreign key
外键约束是保证一个或两个表之间的参照完整性,外键是构建于一个表的两个字段或是两个表的两个字段之间的参照关系。 也就是说从表的外键值必须在主表中能找到或者为空。 当主表的记录被从表参照时,主表的记录将不允许删除,如果要删除数据,需要先删除从表中依赖该记录的数据, 然后才可以删除主表的数据。还有一种就是级联删除子表数据。
注意:外键约束的参照列,在主表中引用的只能是主键或唯一键约束的列,假定引用的主表列不是唯一的记录, 那么从表引用的数据就不确定记录的位置。同一个表可以有多个外键约束。
check
check约束针对Mysql数据库来说,没有起作用。通过检索网上信息,说check约束,仅仅是一个摆设而已,好吧,期待新版本添加此功能。
创建表t3
CREATE TABLE `t3` (
`id1` INT(11) NOT NULL DEFAULT '0',
`id2` INT(3) UNSIGNED ZEROFILL DEFAULT '0',
CHECK(id1>3)
) ENGINE=MYISAM DEFAULT CHARSET=utf8
执行INSERT INTO t3 VALUES(1,3);
,发现其确实没有起到作用。
备注:以上信息主要是参考以下博文。在此感谢博主的分享。
http://blog.csdn.net/kqygww/article/details/8882990。