选择优化的数据类型

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

    更小的通常更好。

    一般情况下，应该尽量使用可以正确存储数据的最小数据类型。更小的数据类型通常更快，因为它们占用更少的磁盘、内存和cpu缓存，并且处理时需要的cpu周期也更少。但是要确保没有低估需要存储的值的范围，因为在schema中的多个地方增加数据类 型的范围是一个非常耗时和痛苦的操作。如果无法确定哪个数据类型是最好的，就 选择你认为不会超过范围的最小类型。（如果系统不是很忙或者存储的数据量不多， 或者是在可以轻易修改设计的早期阶段，那之后修改数据类型也比较容易）。

    简单就好

    简单数据类型的操作通常需要更少的CPU周期。例如，整型比字符操作代价更低， 因为字符集和校对规则(排序规则)使字符比较比整型比较更复杂。这里有两个例子: 一个是应该使用MySQL内建的类型而不是字符串来存储日期和时间，另外一个 是应该用整型存储IP地址。稍后我们将专门讨论这个话题。

    尽量避免NULL

    很多表都包含可为NULL (空值）的列，即使应用程序并不需要保存NULL也是如此， 这是因为可为NULL是列的默认属性。通常情况下最好指定列为NOT NULL，除非真 的需要存储NULL值。如果査询中包含可为NULL的列，对MySQL来说更难优化，因为可为NULL的列使 得索引、索引统计和值比较都更复杂。可为NULL的列会使用更多的存储空间，在 MySQL里也需要特殊处理。当可为NULL的列被索引时，每个索引记录需要一个额外的字节，在MylSAM里甚至还可能导致固定大小的索引（例如只有一个整数列的 索引）变成可变大小的索引。通常把可为NULL的列改为NOT NULL带来的性能提升比较小，所以（调优时）没有必要首先在现有schema中査找并修改掉这种情况，除非确定这会导致问题。但是，如果计划在列上建索引，就应该尽量避免设计成可为NULL的列。当然也有例外，例如值得一提的是，InnoDB使用单独的位（bit)存储NULL值，所 以对于稀疏数据有很好的空间效率。但这一点不适用于MylSAM。

    在为列选择数据类型时，第一步需要确定合适的大类型：数字、字符串、时间等。这通 常是很简单的，但是我们会提到一些特殊的不是那么直观的案例。

    下一步是选择具体类型。很多MySQL的数据类型可以存储相同类型的数据，只是存储 的长度和范围不一样、允许的精度不同，或者需要的物理空间（磁盘和内存空间）不同。 相同大类型的不同子类型数据有时也有一些特殊的行为和属性。

    例如，DATETIME和TIMESAMP列都可以存储相同类型的数据：时间和日期，精确到秒。然而TIMESTAMP只使用DATETIME —半的存储空间，并且会根据时区变化，具有特殊的自 动更新能力。另一方面，TIMESTAMP允许的时间范围要小得多，有时候它的特殊能力会成为障碍。

    MySQL为了兼容性支持很多别名，例如INTEGER、BOOL，以及NUMERIC。它们都只是别名。这些别名可能令人不解，但不会影响性能。如果建表时采用数据类型的别名，然后用SHOW CREATE TABLE检査，会发现MySQL报告的是基 本类型，而不是别名。

转载于:https://my.oschina.net/u/2427170/blog/598911