最近刚入职新公司，发现数据库设计有点小问题，数据库字段很多没有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/ref...
  2. https://dev.mysql.com/doc/ref...
  3. https://dev.mysql.com/doc/ref...
  4. https://dev.mysql.com/doc/ref...
  5. https://www.cnblogs.com/zhouj...