背景
DBA 又把建表语句打回来了，原因是字段可空了!理由是为了省空间！！！！
语句如下：
正文
InnoDB 页的概念
Page 是 Innodb 存储的最基本结构，也是 Innodb 磁盘管理的最小单位，与数据库相关的所有内容都存储在 Page 结构里。
MySQL 的客户端和服务端的交互最小单位也是 Innodb 页（默认大小为 16K），也就是说如果你即使只查询一条记录，一次至少从磁盘上读取 16K 的内容到内存中。
Innodb 行格式
我们平时往数据库插入一条条的记录，这些记录在磁盘上存放格式也是以行记录的方式的。
Innodb 存储引擎目前有四种格式--COMPACT、REDUNDANT、DYNAMIC、COMPRESSED
从 MySQL5.7 开始，默认是 DYNAMIC 方式，我们用图片来看一下 Innodb 行格式大概示意图。（这里以 COMPACT为例，因为这 2 者基本上是一样的，只有一些细微的差别）
记录额外信息
这里只讲变长属性长度列表、NULL 值列表 2 个部分
1、变长属性长度列表
常见的关系型数据库都支持变长属性，比如上面的语句username varchar(64)中，64 是代表可存储的最大的字符数，如果某条记录的名字是“张三”，会有什么样的问题呢
我们来举一个栗子：
上面的记录 user_name,email,nick_name,address 都是 varchar 类型的，那么他存储的记录格式是什么样的呢
上图中的 09、0b、06、09 分别对应 user_name,email,nick_name、address 对应字节长度，16 进制（实际上无空格，这里只是为了方便看）。
至于为什么是倒序放的，不是本文重点，这里先不做解答
小彩蛋：varchar(M)中的 M 代表能存储的最大字符数，实际存储时都是按照字节来计算的，所以一个字段占用的实际字节数的公式：
“
RL（存储属性最多的字节数）=M（最多字符数）* W（当前字符集下最多需要几个字节表示一个字符）
”
所以在编码是 utf8mb4 的情况下，user_name 最多占用的字节数=64 * 4 = 256，所以该属性需要 2 个字节表示长度
为什么不是 1 个字节，1 个字节不正好是 256 吗？因为第一位是标记位，如果第一位是 0，表示用 1 个字节就可以表示该属性的长度，如果第一位是 1，表示需要用 2 个字节表示该属性的长度。
但是如果RL大于256，占用的字节也是2个，字段属性值保存一部分或者（数据地址）
如果另一条记录是这样的：
则对应的行格式如下：
昵称、家庭住址为空，则不在变长长度列表中出现。
2、NULL 值列表
我们在插入一条记录时，Innodb 引擎怎么处理
先统计允许为 NULL 的列有哪些
如果建表语句中，没有可空的字段，就没有 NULL 值列表；如果有可空的字段，那么每个可空字段对应一个二进制位，1-代表 NULL，0-不为 NULL
最小单位需要用字节来表示 NULL 值列表，如果只有 2 个可空值，至少也需要 1 个字节来表示，高位补 0，如张无忌对应的 NULL 值列表为 00000011，张三丰对应的 NULL 值列表为 00000000
张三丰对应的记录行格式（00000000）：
张无忌对应的记录行格式(00000011)：
综上
如果一张表没有可空的字段，比如建表语句如下：
语句如下：
对应的行结构如下：
没有 NULL 值列表哪一项，但是虽然 NULL 列表中没有了，变长列表中会有，同时真实数据部分也会有，占用的空间更大，可见为了省空间这种说法站不住脚。
总结
原因到底是为什么呢？
MySQL 官方有那么一句话：
中文意思是：
照此看来，官方说法是其中一点原因，站在Innodb的行格式上，不见得是省空间的。
所有使用 NULL 值的情况，都可以通过一个有意义的值的表示，这样有利于代码的可读性和可维护性，并能从约束上增强业务数据的规范性。
NULL 值到非 NULL 的更新无法做到原地更新，更容易发生索引分裂，从而影响性能。
NULL 值在 timestamp 类型下容易出问题，特别是没有启用参数 explicit_defaults_for_timestamp
NOT IN、!= 等负向条件查询在有 NULL 值的情况下返回永远为空结果，查询容易出错，不是自己想要的结果，甚至可能出现重大损失
