为何数据库字段要使用NOT NULL？

最近刚入职新公司，发现数据库设计有点小问题，数据库字段不少没有NOT NULL，对于强迫症晚期患者来讲，简直难以忍受，所以有了这篇文章。

基于目前大部分的开发现状来讲，咱们都会把字段所有设置成NOT NULL而且给默认值的形式。

一般，对于默认值通常这样设置：

1. 整形，咱们通常使用0做为默认值。

2. 字符串，默认空字符串

3. 时间，能够默认1970-01-01 08:00:01，或者默认0000-00-00 00:00:00，可是链接参数要添加zeroDateTimeBehavior=convertToNull，建议的话仍是不要用这种默认的时间格式比较好

可是，考虑下缘由，为何要设置成NOT NULL？

来自高性能Mysql中有这样一段话：

尽可能避免NULL

不少表都包含可为NULL（空值）的列，即便应用程序并不须要保存NULL也是如此，这是由于可为NULL是列的默认属性。一般状况下最好指定列为NOT NULL，除非真的须要存储NULL值。

若是查询中包含可为NULL的列，对MySql来讲更难优化，由于可为NULL的列使得索引、索引统计和值比较都更复杂。可为NULL的列会使用更多的存储空间，在MySql里也须要特殊处理。当可为NULL的列被索引时，每一个索引记录须要一个额外的字节，在MyISAM里甚至还可能致使固定大小的索引（例如只有一个整数列的索引）变成可变大小的索引。

一般把可为NULL的列改成NOT NULL带来的性能提高比较小，因此（调优时）没有必要首先在现有schema中查找并修改掉这种状况，除非肯定这会致使问题。可是，若是计划在列上建索引，就应该尽可能避免设计成可为NULL的列。

固然也有例外，例如值得一提的是，InnoDB使用单独的位（bit）存储NULL值，因此对于稀疏数据有很好的空间效率。但这一点不适用于MyISAM。

书中的描述说了几个主要问题，我这里暂且抛开MyISAM的问题不谈，这里我针对InnoDB做为考量条件。

1. 若是不设置NOT NULL的话，NULL是列的默认值，若是不是自己须要的话，尽可能就不要使用NULL
2. 使用NULL带来更多的问题，好比索引、索引统计、值计算更加复杂，若是使用索引，就要避免列设置成NULL
3. 若是是索引列，会带来的存储空间的问题，须要额外的特殊处理，还会致使更多的存储空间占用
4. 对于稀疏数据又更好的空间效率，稀疏数据指的是不少值为NULL，只有少数行的列有非NULL值的状况

默认值

对于MySql而言，若是不主动设置为NOT NULL的话，那么插入数据的时候默认值就是NULL。

NULL和NOT NULL使用的空值表明的含义是不同，NULL能够认为这一列的值是未知的，空值则能够认为咱们知道这个值，只不过他是空的而已。

举个例子，一张表中的某一条name字段是NULL，咱们能够认为不知道名字是什么，反之若是是空字符串则能够认为咱们知道没有名字，他就是一个空值。

而对于大多数程序的状况而言，没有什么特殊须要非要字段要NULL的吧，NULL值反而会对程序形成好比空指针的问题。

对于现状大部分使用MyBatis的状况来讲，我建议使用默认生成的insertSelective方法或者纯手动写插入方法，能够避免新增NOT NULL字段致使的默认值不生效或者插入报错的问题。

值计算

聚合函数不许确

对于NULL值的列，使用聚合函数的时候会忽略NULL值。

如今咱们有一张表，name字段默认是NULL，此时对name进行count得出的结果是1，这个是错误的。

count(*)是对表中的行数进行统计，count(name)则是对表中非NULL的列进行统计。

=失效

对于NULL值的列，是不能使用=表达式进行判断的，下面对name的查询是不成立的，必须使用is NULL。

与其余值运算

NULL和其余任何值进行运算都是NULL，包括表达式的值也是NULL。

user表第二条记录age是NULL，因此+1以后仍是NULL，name是NULL，进行concat运算以后结果仍是NULL。

能够再看下下面的例子，任何和NULL进行运算的话得出的结果都会是NULL，想象下你设计的某个字段若是是NULL还不当心进行各类运算，最后得出的结果。。。

distinct、group by、order by

对于distinct和group by来讲，全部的NULL值都会被视为相等，对于order by来讲升序NULL会排在最前

其余问题

表中只有一条有名字的记录，此时查询名字!=a预期的结果应该是想查出来剩余的两条记录，会发现与预期结果不匹配。

索引问题

为了验证NULL字段对索引的影响，分别对name 和age添加索引。

关于网上不少说若是NULL那么不能使用索引的说法，这个描述其实并不许确，根据引用官方文档[3]里描述，使用is NULL和范围查询都是能够和正常同样使用索引的，实际验证的结果好像也是这样，看如下例子。

而后接着咱们往数据库中继续插入一些数据进行测试，当NULL列值变多以后发现索引失效了。

咱们知道，一个查询SQL执行大概是这样的流程：

首先链接器负责链接到指定的数据库上，接着看看查询缓存中是否有这条语句，若是有就直接返回结果。

若是缓存没有命中的话，就须要分析器来对SQL语句进行语法和词法分析，判断SQL语句是否合法。

如今来到优化器，就会选择使用什么索引比较合理，SQL语句具体怎么执行的方案就肯定下来了。

最后执行器负责执行语句、有无权限进行查询，返回执行结果。

从上面的简单测试结果其实能够看到，索引列存在NULL就会存在书中所说的致使优化器在作索引选择的时候更复杂，更加难以优化。

存储空间

数据库中的一行记录在最终磁盘文件中也是以行的方式来存储的，对于InnoDB来讲，有4种行存储格式：REDUNDANT、 COMPACT、 DYNAMIC 和 COMPRESSED。

InnoDB的默认行存储格式是COMPACT，存储格式以下所示，虚线部分表明可能不必定会存在。

变长字段长度列表：有多个字段则以逆序存储，咱们只有一个字段全部不考虑那么多，存储格式是16进制，若是没有变长字段就不须要这一部分了。

NULL值列表：用来存储咱们记录中值为NULL的状况，若是存在多个NULL值那么也是逆序存储，而且必须是8bit的整数倍，若是不够8bit，则高位补0。1表明是NULL，0表明不是NULL。若是都是NOT NULL那么这个就存在了。

ROW_ID：一行记录的惟一标志，没有指定主键的时候自动生成的ROW_ID做为主键。

TRX_ID：事务ID。

ROLL_PRT：回滚指针。

最后就是每列的值。

为了说明清楚这个存储格式的问题，我弄张表来测试，这张表只有c1字段是NOT NULL，其余都是能够为NULL的。

可变字段长度列表：c1和c3字段值长度分别为1和2，因此长度转换为16进制是0x01 0x02，逆序以后就是0x02 0x01。

NULL值列表：由于存在容许为NULL的列，因此c2,c3,c4分别为010，逆序以后仍是同样，同时高位补0满8位，结果是00000010。

其余字段咱们暂时无论他，最后第一条记录的结果就是，固然这里咱们就不考虑编码以后的结果了。

这样就是一个完整的数据行数据的格式，反之，若是咱们把全部字段都设置为NOT NULL，而且插入一条数据a,bb,ccc,dddd的话，存储格式应该这样：

虽然咱们发现NULL自己并不会占用存储空间，可是若是存在NULL的话就会多占用一个字节的标志位的空间。

文章参考文档：

1. https://dev.mysql.com/doc/refman/8.0/en/problems-with-null.html
2. https://dev.mysql.com/doc/refman/8.0/en/working-with-null.html
3. https://dev.mysql.com/doc/refman/5.6/en/is-null-optimization.html
4. https://dev.mysql.com/doc/refman/5.6/en/innodb-row-format.html
5. https://www.cnblogs.com/zhoujinyi/articles/2726462.html