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

目录

• 一、性能
• 二、开发的友好性
• 三、聚合函数不准确
• 四、null与其它值计算
• 五、distinct、group by、order by的问题
• 六、索引问题
• 七、其它问题

一、性能

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

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

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

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

二、开发的友好性

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

三、聚合函数不准确

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

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

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

四、null与其它值计算

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

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

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

六、索引问题

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

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

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

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

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

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

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

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

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

七、其它问题

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

到此这篇关于为什么数据库字段建议设置为NOT NULL的文章就介绍到这了,更多相关数据库字段NOT NULL内容请搜索编程客栈(www.devze.com)以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程客栈(www.devze.com)！