开发笔记:#yyds干货盘点#MySQL性能优化：选择优化的数据类型

篇首语：本文由编程笔记#小编为大家整理，主要介绍了#yyds干货盘点# MySQL性能优化：选择优化的数据类型相关的知识，希望对你有一定的参考价值。

作者：xcbeyond
博客：https://xcbeyond.cn/ 公众号：程序猿技术大咖

良好的设计是高性能的基石，应该根据系统的实际业务需求、使用场景进行设计、优化、再调整，在这其中往往需要权衡各种因素，例如，数据库表究竟如何划分、字段如何选择合适的数据类型等等问题。

mysql支持的数据类型非常之多，对于选择恐惧症的小伙伴而言，苦不可言。大部分人在创建数据库表时，基本一股脑的使用INT、VARCHAR这两种类型最多，至于长度，则会选择足够大即可，避免日后不够用咋办。只顾当时一时爽，之后坑谁谁难受。

如果你是一个追求极致、高效的开发者，对于上面的情况肯定是不愿让其发生的。在众多的数据类型面前，如何选择正确的数据类型，对于高性能是至关重要的。本文将介绍如何选择优化的数据类型，来提高MySQL的性能，将会选取最为常用的类型进行说明，便于在实际开发中创建表、优化表字段类型时提供帮助。

不管存储哪种类型的数据，下面几个简单的原则将有助于你做出更好的选择。

1.更小的通常更好

一般情况下，应该尽可能选择正确存储数据的最小数据类型。更小的数据类型通常更快，因为它们占用更少的磁盘空间、内存，并且处理时需要的CPU周期更少。

但是，在选择更小数据类型时，一定不要低估存储值的范围，因为后期修改数据类型及长度是一件非常痛苦、耗时的操作。如果无法确定哪个数据类型是最好的，就选择你认为不会超过范围的最小类型。

2.简单就好

简单的数据类型操作通常需要更少的CPU周期。例如，整型比字符操作代价更低，因为字符集和校队规则(如：排序规则)使得字符比较比整型比较更复杂。

3.尽量避免用NULL

NULL是在常见不过的值了，通常都习惯对某些字段设置默认值为NULL，这其实是一种非常不好的习惯。如果查询中的字段值恰巧是设置的NULL值，对MySQl来说更难优化，因为可为NULL的字段使得索引、值比较都更复杂。

NULL值不能进行索引，影响索引的统计信息，影响优化器的判断。复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。

字符串类型是数据库中使用频率最高的数据类型，VARCHAR和CHAR是两种最主要的字符串类型，都可以用来存储字符串，但它们保存和检索的方式不同。VARCHAR属于可变长度的字符类型，而CHAR属于固定长度的字符类型。下面是关于这两种类型的说明、比较。

1.VARCHAR

VARCHAR类型用于存储可变长字符串，它比定长类型更节省空间，因为它仅使用必要的空间(例如，越短的字符串使用最少的空间)。

VARCHAR需要使用1或2个额外的字节来记录字符串的长度（如果字段的最大长度小于或等于255字节，则只使用1个字节表示长度，否则使用2个字节来表示长度）。例如，一个VARCHAR(10)的字段需要11个字节的存储空间，VARCHAR(1000)则需要1002个字节的存储空间，其中需要2个字节来存储长度。

2.CHAR

CHAR类型是定长的。当数据类型为CHAR时，MySQL会删除所有的末尾空格。

CHAR类型适合存储很短的字符串，或者所有值都接近同一个长度。例如，CHAR类型非常适合存储密码的MD5值，因为这是一个定长的值。对于经常变更的数据，CHAR类型也比VARCHAR类型更好，因为定长的CHAR类型不容易产生碎片。对于存储非常短的列，CHAR类型比VARCHAR在存储空间上更有效率。例如，用CHAR(1)来存储只有Y和N的值，如果采用VARCHAR(1)却需要2个字节，因为还会有一个记录长度的额外字节。

通过下面具体例子来对CHAR进行说明，有助于更好的理解。这里创建一张只有一个CHAR(10)字段的表char_test，并往里面插入三个字符串xcbeyond，注意前后有空格的区别：

mysql> create table char_test(ch char(10));
Query OK, 0 rows affected
mysql> insert into char_test(ch) values(xcbeyond),( xcbeyond),(xcbeyond );
Query OK, 3 rows affected
Records: 3 Duplicates: 0 Warnings: 0

奇怪的事情发生了，当我们查询时，会发现第三个字符串末尾的空格被自动截断了。为了更好的显示出是否有空格，对ch字段前后拼接字符便于查看对比。

mysql> select concat("",ch,"") from char_test;
+--------------------+
| concat("",ch,"") |
+--------------------+
| xcbeyond |
| xcbeyond |
| xcbeyond |
+--------------------+
3 rows in set

如果用VARCHAR(10)字段存储相同的值，则字符串末尾的空格是不会被截断的。

MySQL提供了两种相似的日期类型：DATETIME和TIMESTAMP,使用起来傻傻分不清，看完本节后不要再说不知道如何选择了。

对于应用程序而言，他们都能很好的表示日期，但是再某些场景下，各有不同。接下来让我们一起看看吧。

1.DATETIME

DATETIME类型能够保持很大范围的日期，从1001年到9999年，精度为秒。它把日期和时间封装到格式为YYYYMMDDHHMMSS的整数中，与时区无关，使用8个字节的存储空间。

默认情况下，MySQL是以一种可排序、无歧义的格式显示DATETIME值，例如2020-03-05 22:38:40。

2.TIMESTAMP

TIMESTAMP，从它的名字不难看出，它和UNIX时间戳相同，保存了从1970年1月1日0时0分0秒以来的秒数。TIMESTAMP只使用4个字节的存储空间，因此它的范围比DATETIME小得多，只能表示从1970年到2038年。

TIMESTAMP显示的值依赖于时区，MySQL服务器、操作系统，以及客户端连接都有时区设置。因此，存储值为0的TIMESTAMP在美国东部时区显示为1969-12-31 19:00:00，与格林尼治时差5个小时。

通常应该尽量使用TIMESTAMP，因为它比DATETIME更节省存储空间，而且对于跨时区的业务，TIMESTAMP更为合适。

如果需要存储比秒更小粒度的日期和时间值该怎么办？MySQL目前没有提供合适的数据类型，但可以采用其他变通的方式，如可以使用自己的存储格式：可以使用BIGINT类型存储微妙级别的时间戳，或者使用DOUBLE存储秒之后的小数部分。或者也可以使用MariaDB数据库替代MySQL。

一般在保存少了字符串的时候，我们会选择CHAR或VARCHAR类型，而在保存较大文本等数据时，通常会选择使用TEXT和BLOB。

TEXT和BLOB类型都是存储很大的数据而设计的字符串数据类型，分别采用字符串和二进制方式存储。例如，TEXT通常用来保存文章内容、日志等字符串内容，而BLOB通常用来保存图片、视频等二进制数据内容。有如下特点：

• TEXT类型有字符集和排序规则。

  
  


• BLOB类型存储的是二进制数据，没有排序规则或字符集。


• MySQL中不能将TEXT和BLOB类型的列进行索引，也不能使用这些索引消除排序。

与其他数据类型不同，MySQL把每个TEXT和BLOB类型的值当作一个独立的对象处理。存储引擎在存储时通常会做特殊处理，当它们的值太大时，InnoDB会使用专门的“外部”存储区域来进行存储，此时每个值在行内需要1~4个字节来存储一个指针，然后在外部存储区域存储实际的值。

在面对TEXT、BLOB之间的选择时，应该根据实际情况选择能够满足需求的最小存储类型，接下来主要针对TEXT、BLOB类型存在的一些常见问题进行介绍。

1.在执行了大量的删除操作时，TEXT和BLOB会引起一些性能问题

删除操作会在数据库表中留下很大的“空洞”，以后填入这些“空洞”的记录在插入的性能上会有影响。为了提高性能，建议定期使用OPTIMZE TABLE功能对这类表进行碎片整理，避免因为“空洞”导致性能问题。

实战演示验证说明如下：

1）创建测试表text_test，字段id和context的类型分别为int(11)和text:

mysql> create table text_test(id int(11),context text);
Query OK, 0 rows affected

2）往表text_test中插入大量的数据，这里使用repeat函数插入字符串：

mysql> insert into text_test(id,context) values(1,repeat(xcbeyond,1000));
Query OK, 1 row affected
mysql> insert into text_test(id,context) values(2,repeat(xcbeyond,1000));
Query OK, 1 row affected
mysql> insert into text_test(id,context) values(3,repeat(xcbeyond,1000));
Query OK, 1 row affected
mysql> insert into text_test(id,context) values(4,repeat(xcbeyond,1000));
Query OK, 1 row affected
mysql> insert into text_test(id,context) values(5,repeat(xcbeyond,1000));
Query OK, 1 row affected
mysql> insert into text_test(id,context) values(6,repeat(xcbeyond,1000));
Query OK, 1 row affected
……

3）此时看看表text_test的物理文件大小：

2020/03/07 周六 15:58 540,672 text_test.ibd

这里显示数据文件大小为540Kb。

4）从表text_test中删除一大部分数据，这些数据占总数据量的2/3：

mysql> delete from text_test where id <10;
Query OK, 9 rows affected

5）在此查看text_test的物理文件大小：

2020/03/07 周六 16:05 573,440 text_test.ibd

奇怪的是，数据文件大小并没有因为删除数据而减少，反而还增加了一点。

6）接下来对表text_test进行OPTIMIZE优化操作：

mysql> optimize table text_test;
+----------------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+----------------+----------+----------+-------------------------------------------------------------------+
| test.text_test | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.text_test | optimize | status | OK |
+----------------+----------+----------+-------------------------------------------------------------------+
2 rows in set

7）再次查看表text_test的物理文件大小：

2020/03/07 周六 16:08 458,752 text_test.ibd

可以发现，表的数据文件大小减少了，则说明“空洞”空间已经被回收了。

2.使用合成索引来提高大文本字段(TEXT、BLOB类型)的查询性能

合成索引，就是根据大文本字段的内容建立一个散列值，并把这个值存储在单独的数据列中，接下来就可以通过检索散列值找到数据行了。

但是，要注意这种技术只能用于精确匹配的查询（散列值对于类似<或>=等范围搜索操作符是没有用处的）。可以使用MD5()函数生成散列值，也可以使用SHA1()或 CRC32()，或者使用自己的应用程序逻辑来计算散列值。请记住数值型散列值可以很高效率地存储。同样，如果散列算法生成的字符串带有尾部空格，就不要把它们存储在CHAR 或 VARCHAR列中，它们会受到尾部空格去除的影响。合成的散列索引对于那些 BLOB或 TEXT数据列特别有用。用散列标识符值查找的速度比搜索BLOB列本身的速度快很多。

实战演示验证说明如下：

1）创建测试表text_test2，字段id、context、hashValue字段类型分别为int(11)、text、varchar(40):

mysql> create table text_test2(id int(11),context text,hashValue varchar(40));
Query OK, 0 rows affected

2）往表text_test2中插入数据，其中hashValue用来存入context列内容的MD5值：

mysql> insert into text_test2 values(1,repeat(xcbeyond,10),md5(context));
Query OK, 1 row affected
mysql> insert into text_test2 values(2,repeat(xcbeyond,10),md5(context));
Query OK, 1 row affected
mysql> select * from text_test2;
+----+----------------------------------------------------------------------------------+----------------------------------+
| id | context | hashValue |
+----+----------------------------------------------------------------------------------+----------------------------------+
| 1 | xcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyond | 537f6020f5b2b59456a61271a2b3f285 |
| 2 | xcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyond | 537f6020f5b2b59456a61271a2b3f285 |
+----+----------------------------------------------------------------------------------+----------------------------------+
2 rows in set

3）如果需要查询context列的值，则通过散列值hashValue来查询：

mysql> select * from text_test2 where hashValue = md5(repeat(xcbeyond,10));
+----+----------------------------------------------------------------------------------+----------------------------------+
| id | context | hashValue |
+----+----------------------------------------------------------------------------------+----------------------------------+
| 1 | xcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyond | 537f6020f5b2b59456a61271a2b3f285 |
| 2 | xcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyondxcbeyond | 537f6020f5b2b59456a61271a2b3f285 |
+----+----------------------------------------------------------------------------------+----------------------------------+
2 rows in set

上面的例子则是展示了合成索引的用法，由于这种技术只能用于精确匹配，在一定程度上减少 I/O，从而提高查询效率。

3.在不必要的情况下避免检索TEXT、BLOB类型的值

例如，SELECT * 查询就不是很好的操作，除非能够确定作为约束条件的 WHERE 子句只会找到所需要的数据行。否则，很可能毫无目的地在网络上传输大量的值。这也是 BLOB 或 TEXT标识符信息存储在合成的索引列中对用户有所帮助的例子。用户可以搜索索引列，决定需要的哪些数据行，然后从符合条件的数据行中检索 BLOB 或 TEXT 值。

4.把 BLOB 或 TEXT 列分离到单独的表中

在某些环境中，如果把这些数据列移动到第二张数据表中，可以把原数据表中的数据列转换为固定长度的数据行格式，那么它就是有意义的。这会减少主表中的碎片，可以得到固定长度数据行的性能优势。它还可以使主数据表在运行 SELECT * 查询的时候不会通过网络传输大量的 BLOB 或 TEXT 值。

唯一标识符，也就是我们常常所说的主键，用于充当表记录的唯一判断依据。唯一标识符，选择合适的数据类型是非常重要的。

通常唯一标识符更多的是用来与其它值或者其它表的值进行比较（如，关联查询中），标识列也可能在其它表中作为外键使用，所以为标识列选择数据类型时，应该选择根关联表中对应列一样的类型。

当选择唯一标识符的类型时，不仅仅需要考虑存储类型，还需要考虑MySQL对这种类型怎么执行计算和比较的，因为比较在SQL查询中使用最多，而且也是制约性能的最大因素。

一旦选定了一种类型，就一定要确保所有关联表中都使用相同的类型。因为类型直接往往都是需要精确匹配，混用不同数据类型可能导致性能问题，即使没有性能影响，在比较操作时隐式类型转换也可能导致很难发现的错误问题。

在可以满足值的范围的需求，并且预留未来增长空间的前提下，应该选择最小的数据类型。

下面是一些小技巧：

1.整数类型

整数通常是标识列最好的选择，因为它很快，并且可以使用AUTO_INCREMENT。

2.字符串类型

如果可以避免，尽可能的避免使用字符串类型作为标识列的类型，因为它很消耗空间，并且通常比数字类型慢。尤其是在MyISAM存储引擎的表里使用字符串作为标识列时，要特别的小心，MyISAM默认对字符串使用压缩索引，这会导致查询慢很多。

对于完全“随机”的字符串也需多加注意，例如MD5()、SHA1()或者UUID()产生的字符串。这些函数生成的新值会任意分布在很大的空间内，会导致insert以及一些select操作变得很慢：

• 因为插入值会随机地写到索引的不同位置，所以使得insert语句更慢。这会导致页分裂、磁盘随机访问。


• select语句会变得更慢，是因为逻辑上不相邻的数据会分布在磁盘和内存的不同地方。


• 随机值会导致缓存对所有类型的查询语句效果很差，因为会使得缓存赖以工作的访问局部性原理失效。

在实际开发中，有很多工具会自动生成建表脚本等等，自动生成前期给开发带来了很大的便利，但与此同时却导致严重的性能问题。有些工具生成的东西，在存储任何数据都会使用很大的VARCHAR类型，这往往是不正确的。如果是自动生成的，一定要反复检查确认是否合理。

例如，一些ORM框架(如，MyBatis、Hibernate)，会存储任意类型的数据列到任意类型的后端数据，这通常意味着没有设计使用更优的数据类型来存储，后期安全隐患很大，出现问题也很难排查。总之，一定要反复检查确认是否合理。这也是我个人不太喜欢用这类类似的工具，来生成代码的原因，检查真的很浪费我的时间。

在这里已经介绍了大部分常用的数据类型，各自都有哪些特点，哪些地方会严重影响性能等等。在选择数据类型时，把握好“选择原则”，你就成功了一半，其余细节在日常开发接触中慢慢琢磨、留意，选择类型时不要随意、盲目选择就好。

简单归纳如下：

• 对于字符串类型，最好的策略是只分配真正需要的空间。

  
  



• 日期类型，要根据实际需要选择能够满足应用的最小存储的日期类型。

  
  


• 对含有 TEXT 和BLOB字段的表，如果经常做删除和修改记录的操作要定时执行OPTIMIZE TABLE功能对表进行碎片整理。