港真，Null 貌似在哪里都是个头疼的问题，比如 Java 里让人头疼的 NullPointerException，为了避免猝不及防的空指针异常，千百年来程序猿们不得不在代码里小心翼翼的各种 if 判断，麻烦而又臃肿，为此 java8 引入了 Optional 来避免这一问题。下面咱们要聊的是 MySQL 里的 null，在大量的 MySQL 优化文章和书籍里都提到了字段尽可能用NOT NULL，而不是NULL，除非特殊情况。但却都只给结论不说明原因，犹如鸡汤不给勺子一样，让不少初学者对这个结论半信半疑或者云里雾里。本文今天就详细的剖析下使用 Null 的原因，并给出一些不用 Null 的理由。

1、NULL 为什么这么多人用？

2、是不是以讹传讹？

MySQL 官网文档：

NULL columns require additional space in the rowto record whether their values are NULL. For MyISAM tables, each NULL columntakes one bit extra, rounded up to the nearest byte.

Mysql难以优化引用可空列查询，它会使索引、索引统计和值更加复杂。可空列需要更多的存储空间，还需要mysql内部进行特殊处理。可空列被索引后，每条记录都需要一个额外的字节，还能导致MYisam 中固定大小的索引变成可变大小的索引。—— 出自《高性能mysql第二版》照此分析，还真不是以讹传讹，这是有理论依据和出处的。

3、给我一个不用 Null 的理由？

1. 所有使用NULL值的情况，都可以通过一个有意义的值的表示，这样有利于代码的可读性和可维护性，并能从约束上增强业务数据的规范性。
2. NULL值到非NULL的更新无法做到原地更新，更容易发生索引分裂，从而影响性能。
3. NULL值在timestamp类型下容易出问题，特别是没有启用参数explicit_defaults_for_timestamp
4. NOT IN、!= 等负向条件查询在有 NULL 值的情况下返回永远为空结果，查询容易出错
5. Null 列需要更多的存储空间：需要一个额外字节作为判断是否为 NULL 的标志位

举例：

alter table table_3 add index idx_user_name (user_name);

可以看到同样的 varchar(20) 长度，table_2 要比 table_3 索引长度大，这是因为：

两张表的字符集不一样，且字段一个为 NULL 一个非 NULL。

key_len 的计算规则和三个因素有关：数据类型、字符编码、是否为 NULL

1. key_len 62 == 20*3（utf8 3字节） + 2 （存储 varchar 变长字符长度 2字节，定长字段无需额外的字节）
2. key_len 83 == 20*4（utf8mb4 4字节） + 1 (是否为 Null 的标识) + 2 （存储 varchar 变长字符长度 2字节，定长字段无需额外的字节）

本内容属于网络转载，文中涉及图片等内容如有侵权，请联系编辑删除