浅谈为什么数据库字段建议设置为NOT NULL实用指南

平时做技术实践时，很多问题不是概念不会，而是细节没串起来。拿“浅谈为什么数据库字段建议设置为NOT NULL”来说，它看着像小点，放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序，把思路、关键写法和容易踩坑的地方讲清楚，便于大家直接对照操作。

一、性能

实际处理时，若查询中包含可为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预期的结果应该是想查出来剩余的两条记录，会发现与预期结果不匹配。

到此这篇关于为什么数据库字段建议设置为NOT NULL的文章就介绍到这了,更多相关数据库字段NOT NULL内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多兼容脚本之家！