在Mysql中很多表都包含可为NULL（空值）的列，即使应用程序并不需要保存NULL也是如此，这是因为可为NULL是列的默认属性。但我们常在一些Mysql性能优化的书或者一些博客中看到观点：在数据列中，尽量不要用NULL 值，使用0，-1或者其他特殊标识替换NULL值，除非真的需要存储NULL值，那到底是为什么？如果替换了会有什么好处？同时又有什么问题呢？那么就看下面：
- （1）如果查询中包含可为NULL的列，对Mysql来说更难优化，因为可为NULL的列使得索引，索引统计和值比较都更复杂。
- （2）含NULL复合索引无效.
- （3）可为NULL的列会使用更多的存储空间，在Mysql中也需要特殊处理。
- （4）当可为NULL的列被索引时，每个索引记录需要一个额外的字节，在MyISAM里甚至还可能导致固定大小的索引（例如只有一个整数列的索引）变成可变大小的索引。
通常把可为NULL的列改为NOT NULL 带来的性能提升比较小，所以（调优时）没有必要首先在现有schema中查找并修改掉这种情况，除非确定这会导致问题。但是，如果计划在列上建索引，就应该尽量避免设计成可为NULL的列。
当确实需要标识未知值时也不要害怕使用NULL。在一些场景中，使用NULL可能会比某个神奇常数更好。从特定类型的值域中选择一个不可能的值，例如用-1代表一个未知数，可能导致代码复杂的多，并容易引入BUG，还可能让事情变得一团糟（注：Mysql会在索引中存储NULL值，Oracle不会）。
当然也有例外，InnoDB使用单独的位（bit）来存储NULL值，所以对于稀疏数据(很多值位NULL，只有少数行的列有非NULL值)由很好的空间效率，这一点不适用于MyISAM。
所以任何的设计和考虑请注意关注实际需求