摘自《高性能 MySQL》
mysql 支持的数据类型非常多，选择正确的数据类型对于获得高性能至关重要。不管是哪种类型的数据，下面几个简单的原则有助于做出更好的选择。
1. 更新的通常更好
一般情况下，应该尽量使用可以正确储存数据的最小数据类型。更小的数据类型同城更快，因为它们占用更少的磁盘、内存、和 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。
在为列选择数据类型时，第一步需要确定合适的大类型：数字、字符串、时间等。
