Schema的优化和索引 - 选择最佳的数据类型 - 前言

核心提示：越小也就是越好的一般来说，尽量选择小的数据类型足以符合你的存储和展现数据，Schema的优化和索引 - 选择最佳的数据类型 - 前言，越小的数据类型也常常是越快的，因为它们使用了较少的硬盘空间，比如INTEGER,BOOL以及NUMERIC.这些仅仅是别名，它们可能造成一些困惑，内存，CPU缓存

越小也就是越好的

一般来说，尽量选择小的数据类型足以符合你的存储和展现数据。越小的数据类型也常常是越快的，因为它们使用了较少的硬盘空间，内存，CPU缓存。它们也需要更少的CPU处理周期。

要确定的是不要低估你要存储数值的范围，因为在你的Schema的多个位置中，增长的数据类型范围会让操作很费力费时。如果你对不知道选择什么样的数据类型，那么就选择一个最小的，当然要确保数据不会越界。

简单的就是好的

对于简单数据类型的操作，不需要太多的CPU周期。比如，整型之间的比较要比字符之间的比较消耗更低。因为字符集和排序规则使字符的比较过于的复杂。这有两个例子，存储日期和时间要使用MySQL内置类型而不是用字符串，以及对于IP地址你应该使用整型。我们会将在以后的章节详细讨论。

如果可能，要避免使用NULL

当可能的时候，你都应该定义字段为NOT NULL.有许多表包括了许多NULL的列，即使这些应用并不存储NULL。只不过因为这是默认的。除非你打算存储NULL，不然的话你就要小心指定列为NOT NULL.

对于MySQL，优化一些涉及到NULL列的语句是非常困难的，因为它们加索引，索引统计，以及值的比较都很复杂。一个NULL列需要更多的存储空间以及在MySQL内部需要特殊处理。当一个NULL列被索引了，它的每个实体都需要额外的字节，以及设置导致了在MyISAM中，定长的索引转为可变大小（variable-sized）的索引。

即使你需要在字段中不存储值，你也不要用NULL.考虑使用0，特殊的数值，或者空字符串来取代NULL.

把NULL列变为NOT NULL列性能的提高是很小的。因此不要改变已有的Schema,除非你能知道这样做会引起的问题。然而，如果你计划索引列，如果可能的话，请避免使用NULL列。

第一步要决定指定列的适用类型，要大概知道属于哪一类的：数值，字符串，时间等等。这是比较直接的，但是我们提到有些特殊的情况下，选择数据类型并不是很直接的。

第二步选择具体的类型。许多MySQL数据类型保存相同的类型数据，但是它们存储的范围不同，允许的精度，或者它们需要的物理空间（或者硬盘和内存）。一些数据类型有特殊的行为或者属性。

举个例子，DATETIME和TIMESTAMP列能存储相同类型的数据：日期和时间，精度为秒。然而，TIMESTAMP只使用了一半的存储空间，以及有个自动更新的特性。在另一方面，它的值范围较小，以及有的时候这个特性成了一个障碍了。

我们讨论的都是基本类型。MySQL也兼容别名，比如INTEGER,BOOL以及NUMERIC.这些仅仅是别名。它们可能造成一些困惑，但是不会影响性能。