MySQL 关于去除约束的问题

现在要说的是在列这一层次过滤的基于表定义之前就规范好的 CHECK 约束。（MySQL 版本 >= 8.0.16）

mysql>create table f1 (r1 int constraint tb_f1_r1_chk1 check (mod(r1,3)=0))

Query OK, 0 rows affected (0.03 sec)

mysql>create table f2 (r1 int constraint tb_f2_r1_chk1 check (mod(r1,3)=0) not enforced)

Query OK, 0 rows affected (0.02 sec)

这里 CHECK 约束的相关限制如下：

1. constraint 名字在每个数据库中唯一。

也就是说单个数据库里不存在相同的两个 constraint，如果不定义，系统自动生成一个唯一的约束名字。

2. check 约束针对语句 insert/update/replace/load data/load xml 生效；针对对应的 ignore 语句失效。

3. 并非每个函数都可以使用，比如函数结果不确定的：NOW()，CONNECTION_ID()，CURRENT_USER()。

4. 不适用于存储过程和存储函数。

5. 系统变量不适用。

6. 子查询不适用。

7. 外键动作（比如 ON UPDATE, ON DELETE） 不适用。

8. enforced 默认启用，如果单独加上 not enforced ，check 约束失效。

主码完整性约束的设置有两种方法：1.在定义数据项的时候就声明它为主码2.在表创建完成之后增加完整性约束对应于1，撤销完整性约束alter table employeedrop primary key对应于2.alter table emloyeedrop constraint PK_enoPK_eno 为当初创建完整性约束时为该约束性定义的名字

NULL 对外部程序来说，具体为不知道、不确切的、无法表述的值。所以在很多家公司的开发规范里都明确规定了，必须为 NOT NULL。

其实用到 NULL 的场景都可以转换为有意义的字符或者数值，一是有利用数据的易读性以及后期的易维护性；二是降低 SQL 语句的编写难度。

关于 NULL 的特性如下：

1. 参与 NULL 字段拼接的结果都为 NULL，预期的可能会有差异

预想把字段 r1 做个拼接，再插入到新的表 t3 里，结果 t3 表的记录全为 NULL，跟预期不符。

mysql>show create table t1\G

*************************** 1. row ***************************

Table: t1

Create Table: CREATE TABLE `t1` (

`r1` varchar(10) DEFAULT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

1 row in set (0.00 sec)

mysql>show create table t2\G

*************************** 1. row ***************************

Table: t2

Create Table: CREATE TABLE `t2` (

`r1` varchar(10) NOT NULL

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

1 row in set (0.00 sec)

mysql>create table t3 like t1

Query OK, 0 rows affected (0.04 sec)

mysql>insert into t3 select concat(r1,'database') from t1 limit 2

Query OK, 2 rows affected (0.02 sec)

Records: 2 Duplicates: 0 Warnings: 0

mysql>select * from t3

+------+

| r1 |

+------+

| NULL |

| NULL |

+------+

2 rows in set (0.00 sec)

那正确的方法如下，对 NULL 用函数 IFNULL 特殊处理。

mysql>insert into t3 select concat(ifnull(r1,''),'database') from t1 limit 2

Query OK, 2 rows affected (0.01 sec)

Records: 2 Duplicates: 0 Warnings: 0

mysql>select * from t3

+----------+

| r1 |

+----------+

| database |

| database |

+----------+

2 rows in set (0.00 sec)

2. 对于包含 NULL 列的求 COUNT 值也不准确

t1 和 t2 的记录数是一样的，但是字段 r1 包含了 NULL，这导致结果忽略了这些值。

mysql>select count(r1) as rc from t1

+-------+

| rc|

+-------+

| 16384 |

+-------+

1 row in set (0.01 sec)

mysql>select count(r1) as rc from t2

+-------+

| rc|

+-------+

| 32768 |

+-------+

1 row in set (0.03 sec)

这时候我们可能想到了，正确的方法是用 NULL 相关函数处理，

mysql>select count(ifnull(r1,'')) as rc from t1

+-------+

| rc|

+-------+

| 32768 |

+-------+

1 row in set (0.03 sec)

或者是直接用 COUNT(*) 包含了所有可能的值

mysql>select count(*) as rc from t1

+-------+

| rc|

+-------+

| 32768 |

+-------+

1 row in set (0.02 sec)

当然了不仅仅是 COUNT，除了 NULL 相关的函数，大部分对 NULL 处理都不友好。

所以其实从上面两点来看，NULL 的处理都得特殊处理，额外增加了编写 SQL 的难度。

3. 包含 NULL 的索引列

对包含 NULL 列建立索引，比不包含的 NULL 的字段，要多占用一个 BIT 位来存储。

示例

key_len 分别为 43 和 42，t1 比 t2 多了一个字节，那这里可能有人要问了，不是说占了一个 BIT 位吗？那为什么多了一个字节？可以关注我上一篇文章（第02期：MySQL 数据类型的艺术 - 大对象字段）关于 BIT 的详细描述。

mysql>pager grep -i 'key_len'

PAGER set to 'grep -i 'key_len''

mysql>explain select * from t1 where r1 = ''\G

key_len: 43

1 row in set, 1 warning (0.00 sec)

mysql>explain select * from t2 where r1 = ''\G

key_len: 42

1 row in set, 1 warning (0.00 sec)

4. 各存储引擎相关的对 NULL 的处理

在 MySQL 8.0 发布后，仅有 InnoDB、MyISAM 和 Memory 支持对包含 NULL 列的索引，其他引擎不支持。比如 NDB。

---