【学习笔记】选择优化数据类型的原则

本文属于读书笔记，大部分内容摘抄于《高性能MYSQL》，摘抄内容版权属于原作者。

mysql支持非常多的数据类型，选择正确的数据类型对于获得高性能至关重要。不管存储哪种类型的数据，下面几个简单原则都有助于做出更好的选择：

1. 更小的通常更好；

一般情况下，应该尽量使用可以正确存储数据的最小数据类型（例如只要存0~200， tinyint unsigned更好，而字符串也应该尽量使用限制的最大长度）。更小的数据类型通常更快，因为他们占用更少的磁盘、内存和CPU缓存，并且处理时需要的CPU周期也更少。但是要确保没有低估需要存储的值的范围（如果用户想要存入更多并且这种想法是合理的，但是数据库却无法容纳更大的数，数据库会返回报错，并且在schema中的多个地方增加数据范围是一个非常耗时而且痛苦的操作），基于这种考虑就选择你认为不会超过范围的最小类型。

2. 简单就好

简单数据类型的操作同上需要更少的CPU周期。例如，整型比字符操作的代价更低（处于这种考虑建议在状态值类型设置或有相对应的枚举和字典表的情况下，尽量考虑使用整型而非字符串）。还有两个例子是：应该使用mysql的内建类型而不是字符串来存储日期和时间，另外一个是应该用整型存储IP地址。

3. 尽量避免NULL

更多表都包涵可为NULL的列，即使应用程序并不需要保存NULL也是如此，这是因为可为NULL是列的默认属性。通常情况下最好制定列为NOT NULL，除非需要存储NULL值。如果查询包涵可为NULL的列，对mysql来说更难优化，因为可为NULL的列使得索引、索引统计和值比较都更复杂。可为NULL的列会使用更多的存储空间，在mysql里也需要特殊处理。当可为NULL的列被索引时，每个索引记录需要一个额外的字节，在myISAM里甚至可能还导致固定大小的索引变成可变大小的索引。

通常把可为NULL的列改为NOT NULL带来的性能提升比较小，所以（调优时）没有必要首先在现有的schema中查找并修改掉这种情况，除非确定会导致问题。但是，如果计划在列上建索引，就应该尽量避免设计成可为NULL的列。

当然也有例外，例如值得一提的是， InnoDB使用单独的位（bit）存储NULL值，所以对于稀疏数据有很好的空间效率。但这一点不适用于myISAM。