MySql 数据类型选择与优化

选择优化的数据类型

更小的通常更好
一般情况下尽量使用可以正确存储数据的最小类型。更小的数据类型通常更快，因为它们占用更少的磁盘，内存和CPU缓存，并且处理时需要的CPU周期也更少。但也要确保没有低估需要存储值的范围。
简单就好
简单的数据类型通常需要更少的CPU周期。例如：整型比字符操作代价更低，因为字符集和校对规则（排序规则）使字符比较比整型比较更复杂。例如：应该使用 mysql 的内建类型而不是字符来存储日期和时间，另外一个应该使用整型存储IP地址。
尽量避免 NULL
NULL 使得索引、索引统计和值比较都更复杂

实数类型
DECIMAL 类型用于存储精确的小数。因为CPU 不支持对 DECIMAL 的直接计算，所以在 Mysql 5.0 和更高版本中，Mysql 服务器自身实现了 Decimal 的高精度计算。相对而言，CPU 直接支持原生浮点计算，所以浮点运算明显更快。Decimal 只是一种存储格式，在计算中 Decimal 会转换为 Double 类型。有时候也可以使用 Bigint 替代浮点型。

字符串类型
Varchar
Varchar 节省了存储空间，所以对性能也有帮助。但是，由于是变长的，在 Update 时可能使行长变得比原来更长，这就导致需要做额外的工作，比如导致频繁的页分裂和合并，从而产生大量磁盘碎片。
Char
Char 类型是定长的，当存储 Char 时， Mysql 会删除所有的末尾空格。对于经常变更的数据也不容易产生磁盘碎片。

[!NOTE] 慷慨是不明智的
更长的列会消耗更多的内存，因为 Mysql 通常会分配固定大小的内存块来保存内部值。尤其是使用内存临时表进行排序或操作时会特别糟糕。在使用磁盘临时表进行排序时也同样糟糕。
所以最好的策略是只分配真正需要的空间

BLOB 和 TEXT
Mysql 对 BLOB 和 TEXT 列进行排序与其它类型是不同的：它只对每个列的最前 max_sort_length 字节而不是整个字符串做排序。Memory 引擎不支持 BLOB 和 TEXT 类型，因此在包含 BLOB 和 TEXT 类型的列都会转而使用 MyIsam 磁盘临时表。

日期和时间类型
TIMESTAMP
TIMESTAMP 显示的值也依赖于时区
DATETIME
它把日期和时间封装到格式为 YYYYMMDDHHMMSS 的整数中，与时区无关。

[!NOTE] TIPS
有时候人们会将 UNIX时间戳存储为整数，但这将不会带来任何收益。用整数保存时间戳的格式通常不方便处理，所以我们不推荐这样做。

选择标识符
当选择标识列的类型时，不仅仅需要考虑存储类型，还需要考虑 Mysql 对这种类型怎么计算和比较。一旦选定了一种类型，要确保在所有关联表中都使用同样的类型。类型之间需要精确匹配，包括像 UNSIGNED 这样的属性。混用不同数据类型可能导致性能问题，即使没有性能影响，在比较操作时隐式类型转换也可能导致很难发现的错误。

选择合适的主键
大多数情况使用自增主键ID就可以解决问题，但当我们预估系统会有比较大的业务增长时，可以考虑使用分布式ID作为业务主键，避免后面分库分表时带来的不便

MySQL schema 设计中的陷阱

太多的列
MySQL 的存储引擎API工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据，然后在服务器层将缓冲内容解码成各个列。从行缓冲格式将编码过的列转换成行数据结构的操作代价是非常高的。这个过程是CPU密集型的（太多的列会导致CPU占用过高）。
太多的关联
尽量不关联或者少关联表