为什么数据库字段建议设置为NOT NULL？

目录

一、性能

二、开发的友好性

三、聚合函数不准确

四、null与其它值计算

五、distinct、group by、order by的问题

六、索引问题

七、其它问题

---

一、性能

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

通常把可为null的列改为not null带来的性能提升比较小，所以（调优时）没有必要首先在现有schema中查找并修改掉这种情况，除非确定这会导致问题。但是，如果计划在列上建索引，就应该尽量避免设计成可为null的列。

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

注意：稀疏数据指的是很多值为null，只有少数行的列有非null值的情况。

二、开发的友好性

可以减少对空值的额外处理逻辑，开发人员可以更加简洁和清晰的编写代码。

三、聚合函数不准确

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

现在我们有一张表，name字段默认是null，此时对name进行count得出的结果是1，这个是错误的。

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

四、null与其它值计算

null和其他任何值进行运算都是null，包括表达式的值也是null。比如null+1等于null，concat()函数拼接也还是null。

五、distinct、group by、order by的问题

对于distinct和group by来说，所有的null值都会被视为相等，对于order by来说升序null会排在最前。

六、索引问题

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

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

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

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

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

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

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

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

从上面的简单测试结果其实可以看到，索引列存在null就会导致优化器在做索引选择的时候更复杂，更加难以优化。

七、其它问题

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