目录
目前大部分的开发都会把字段全部设置成NOT NULL并且给默认值。通常,对于默认值一般这样设置:
- 整形,我们一般使用0作为默认值。
- 字符串,默认空字符串
- 时间,可以默认1970-01-01 08:00:01,或者默认 0000-00-00 00:00:00,但是连接参数要添加zeroDateTimeBehavior=convertToNull,建议的话还是不要用这种默认的时间格式比较好.
但是,为什么要设置成NOT NULL?
1 对程序的影响
对于MySql,如果不主动设置为NOT NULL的话,那么插入数据的时候默认值就是NULL。
NULL 和 NOT NULL 使用的空值代表的含义是不一样,NULL可以认为这一列的值是未知的,空值则可以认为我们知道这个值,只不过他是空的而已。
对于大多数程序而言,NULL值不处理可能会造成空指针等问题。
2 对查询结果的影响
2.1 聚合函数count()不准确
count(1) 是对表中的行数进行统计;
count(*) 是对表中的行数进行统计;
count(name) 则是对表中非NULL的列进行统计。
2.1 = 与 != 失效
对于NULL值的列,是不能使用 " = " 表达式进行判断的,下面对name的查询是不成立的,必须使用is NULL。
表中只有一条有名字的记录,此时查询名字 !=a 预期的结果应该是想查出来剩余的两条记录,会发现与预期结果不匹配。
2.3 NULL与其他值运算结果为NULL
NULL和其他任何值进行运算结果都是NULL,包括表达式的值也是NULL。
user表第二条记录:
- age是NULL,所以+1之后还是NULL;
- name是NULL,进行concat运算之后结果还是NULL。
任何与 NULL 进行运算的话得出的结果都会是NULL
2.4 对distinct、group by、order by等排序结果的影响
对于distinct 和 group by来说,所有的NULL值都会被视为相等;
对于order by来说升序NULL会排在最前;
3 对索引的影响
表中索引如下
使用 is NULL 和 范围查询 都是可以和正常一样使用索引的:
往数据库中继续插入一些数据进行测试,当NULL列值变多之后发现索引失效了。
现象解释:
一个查询SQL执行大概是这样的流程:
- 首先连接器负责连接到指定的数据库上,接着看看查询缓存中是否有这条语句,如果有就直接返回结果。
- 如果缓存没有命中的话,就需要分析器来对SQL语句进行语法和词法分析,判断SQL语句是否合法。
- 接下来是优化器对sql执行进行优化,就会选择使用什么索引比较合理,SQL语句具体怎么执行的方案就确定下来了。
- 最后执行器负责执行语句、有无权限进行查询,返回执行结果。
从上面的测试结果其实可以看到,索引列存在过多NULL就会存导致优化器在做索引选择的时候更复杂,更加难以优化,所以优化器会放弃使用索引。
4 对存储空间的影响
数据库中的一行记录在最终磁盘文件中也是以行的方式来存储的,对于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的话就会多占用一个字节的标志位的空间。