高性能MySQL学习总结二----常见数据类型选择及优化

一、数据类型的选择

MySQL的数据类型有很多种，选择正确的数据类型对于获得高性能特别地重要，如何选择合适的数据类型呢？主要遵从以下三个原则：

1.更小的通常情况下性能更好

　　一般情况下，应该尽量使用可以正确存储数据的最小数据类型，比如只需存储0--200的整数，则使用 tinyint unsigned 会比 int 好。更小的数据类型通常更快，因为它们占用更小的磁盘、内存和CPU缓存，并且处理时需要的CPU周期也更少。因此在选择的时候应该选择你认为不会超出范围的最小数据类型。

2.简单即为最好

　　简单数据类型的操作通常情况下需要的CPU周期更小。比如，整型比字符串操作代价更低，因为字符集和校对规则使得字符的比较比整型比较更加的复杂（如：存储时间通常使用date、time、datetime 比使用字符串存储性能更好）。

3.尽量避免NULL

　　在设计表结构时，最好指定列为NOT NUll，除非真正的需要存储NULL值。

　　解释：如果在查询的时候包含有NULL的列，对于MYSQL来说更加的难以优化，因为可以为NULL的列使得索引、索引统计和值比较都非常的复杂。可为NULL的列会使用更多的存储空间，在MYSQL里面也需要特殊的处理。当可以为NULL的列被索引时，每个索引记录需要一个额外的字节，在MyISAM里甚至还可能导致固定大小的索引变为可更改大小的索引（意味着性能受到影响）

二、常见的几种数据类型

1.整数类型

　　tinyint(8位)、smallint（16位）、mediumint（24位）、int（32位）、bigint（64位）

　　整形类型有可选择的unsigned的属性，如果不需要负数，则使用unsigned会使得存储正数的范围提高到一倍，比如tinyint存储范围为-128---127，使用tinyint unsigned存储的范围变为0---255。

　　MySQL可以为整数类型指定宽度例如：int(11)，但是对于大多数应用这是没有意义的：因为它不会限制值得合法范围，只是规定了MySQL的一些交互工具用来显示字符的个数，对于存储和计算来说，int(11)跟int（20）没有任何的区别。

2.实数类型

　　可以使用decimal存储比bigint还大的整数，decimal用来存储精确的小数，在MySQL5.0以上的版本中decimal还支持高精度的计算。decimal可以指定小数点前后所允许的最大位数，MySQL会将数字打包存储在一个二进制的字符串中。浮点类型在存储同样范围的值时，通常比decimal使用更少的空间。

　　选择：因为需要额外的空间计算和开销，所以应该尽量只在对小数进行计算的时候才使用decimal----涉及到财务计算类的业务。但是在数据量比较大的时候可以考虑使用bigint代替decimal，将需要存储的货币单位根据小数的位数乘以相应的倍数即可，这样就可以避免浮点计算的不精确和decimal精确计算的代价高的问题。

3.字符串类型

　　varchar类型：

　　varchar类型用于存储可变长度的字符串，是最常见的字符串数据类型，它比定长类型更加的节省空间，因为它仅仅使用必要的空间，字符串越短存储空间越小；varchar需要使用1到2个额外的字节来记录字符串的长度：如果字符串长度小于255使用1个字节记录反之使用两个字节存储。比如varchar（1000）它需要1002个字节，因为需要两个字节存储字符串的长度。

　　在下面的几种情况下使用varchar是合适的：字符串列的最大长度比平均长度大很多；列的更新很少；使用了utf-8这样的复杂的字符集。

　　char类型：

　　char类型是定长的：MySQL总是根据定义的字符集长度分配足够的空间。char适合存储很短的字符串，或者所有值都接近同一个长度。例如char非常的适合存储密码的MD5值，因为这些值得长度都定长。对于经常变动的值使用char比varchar更好，因为定长的char类型不容易产生碎片。对于非常短的列，char比varchar在存储空间上也有更好的效率。比如在存储“是”和“否”使用char(1)只使用一个字节，使用varchar(1)却需要两个字节，另一个来存储记录的长度。

4.blob和text类型

　　它们两个都被设计来存储很大的字符串类型的数据，blog使用二进制方式存储没有排序规则或字符集，text使用字符串方式存储有排序规则和字符集。与其他数据类型不同的是：MySQL把bolb和text值当做一个独立的对象处理。当它们的值太大时，InnoDB会使用专门的“外部”存储区域进行存储，这时每个值在行内需要1--4个字节存储一个指针，然后在外部存储真实的值。

　　对于bolb和text的排序规则也和其他的数据类型不同：bolb和text会对其中前sort_length字符排序，二不是整个字符串排序，还可以指定前多少个字符进行排序，只需要减少max_sort_length的配置即可。

5.日期和时间类型

　　datetime类型：

　　这个类型能保存最大范围的值，从1001年到9999年，精度为秒。它把日期和时间封装到YYYYMMDDHHMMSS的整数中，使用8个字节的存储空间。

　　timestamp类型：

　　这个类型能保存最大范围的值，从1970年1月1日年到2038年，精度为秒。它只使用4个字节的存储空间，MySQL提供了from_unixtime()函数把unix时间戳转化为日期格式，和unix_timestamp()把日期格式转化为时间戳格式。

　　区别：如果插入的时候timetamp没有指定具体的时间，MySQL会设置这个列为当前的时间，更新的时候回指定更新的时间为当前时间。而datetime则不具有这特性。

　　选择：除了特殊情况下选择datetime(存储时间范围很大)，其他情况下首选timestamp，因为它的空间效率更高。

　　MySQL只支持最小以秒为单位的时间类型，如果需要存储比秒级别更小的时间该任何实现呢？可以使用bigint类型存储微秒级别的时间戳，或者使用double存储秒之后的小数部分。

三、MySQL设计中的一些陷阱

1.太多的列

　　MySQL存储引擎在工作的时候需要在服务器层和存储引擎之间通过行缓冲格式拷贝数据，然后在服务器层将缓冲内容解码成各个列。从行缓冲中将编码过的列传换成数据结构的操作代价是非常高的（注意：MyISAM的定长行结构实际上与服务器层的行结构匹配，所以不需要转化）。当一个表列非常多，但是我们使用到的却只有几列时，这时转化代价就非常的大。

2.太对关联的表

　　MySQL限制了每个关联的操作最多只能有61个表，但是事实上我们通常情况下有可能会超过这个值，而且就算是在61个表之下，解析和优化查询的代价也是非常大的。一个经验就是，如果希望执行查询得快速并且并发性好，单个查询最好是在12个表以内做关联。