为什么mysql字段要使用NOT NULL

最近刚入职新公司,发现数据库设计有点小问题,数据库字段很多没有not null,对于强迫症晚期患者来说,简直难以忍受,因此有了这篇文章。

基于目前大部分的开发现状来说,我们都会把字段全部设置成not null并且给默认值的形式。

  • 通常,对于默认值一般这样设置:
  • 整形,我们一般使用0作为默认值。
  • 字符串,默认空字符串

时间,可以默认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作为考量条件。

  • 如果不设置not null的话,null是列的默认值,如果不是本身需要的话,尽量就不要使用null
  • 使用null带来更多的问题,比如索引、索引统计、值计算更加复杂,如果使用索引,就要避免列设置成null
  • 如果是索引列,会带来的存储空间的问题,需要额外的特殊处理,还会导致更多的存储空间占用
  • 对于稀疏数据又更好的空间效率,稀疏数据指的是很多值为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

对于distinctgroup by来说,所有的null值都会被视为相等,对于order by来说升序null会排在最前

其他问题

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

索引问题

为了验证null字段对索引的影响,分别对nameage添加索引。

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

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

我们知道,一个查询sql执行大概是这样的流程:

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

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

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

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

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

存储空间

数据库中的一行记录在最终磁盘文件中也是以行的方式来存储的,对于innodb来说,有4种行存储格式:redundantcompactdynamiccompressed

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的。

可变字段长度列表:c1c3字段值长度分别为1和2,所以长度转换为16进制是0x01 0x02,逆序之后就是0x02 0x01

null值列表:因为存在允许为null的列,所以c2,c3,c4分别为010,逆序之后还是一样,同时高位补0满8位,结果是00000010

其他字段我们暂时不管他,最后第一条记录的结果就是,当然这里我们就不考虑编码之后的结果了。

这样就是一个完整的数据行数据的格式,反之,如果我们把所有字段都设置为not null,并且插入一条数据a,bb,ccc,dddd的话,存储格式应该这样:

虽然我们发现null本身并不会占用存储空间,但是如果存在null的话就会多占用一个字节的标志位的空间。

文章参考文档:

到此这篇关于为什么mysql字段要使用not null的文章就介绍到这了,更多相关mysql字段使用not null内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com!

(0)
上一篇 2022年3月21日
下一篇 2022年3月21日

相关推荐