mysql由于临时表导致IO过高的性能优化过程分享

左手的ㄟ右手 2022-01-21 10:35 146阅读 0赞

线上mysql数据库爆出一个慢查询，DBA观察发现，查询时服务器IO飙升，IO占用率达到100%， 执行时间长达7s左右。

SQL语句如下：

SELECT DISTINCT g.*, cp.name AS cp_name, c.name AS category_name, t.name AS type_name FROMgm_game g 
    LEFT JOIN gm_cp cp ON cp.id = g.cp_id AND cp.deleted = 0 
    LEFT JOIN gm_category c ON c.id = g.category_id AND c.deleted = 0 \
    LEFT JOIN gm_type t ON t.id = g.type_id AND t.deleted = 0 WHERE g.deleted = 0 ORDER BY g.modify_time DESC LIMIT 20 ;

### 【问题分析】 ###

使用explain查看执行计划，结果如下：

![image][]

这条sql语句的问题其实还是比较明显的： 查询了大量数据(包括数据条数、以及g.\* )，然后使用临时表order by，但最终又只返回了20条数据。

DBA观察到的IO高，是因为sql语句生成了一个巨大的临时表，内存放不下，于是全部拷贝到磁盘，导致IO飙升。

### 【优化方案】 ###

优化的总体思路是拆分sql，将排序操作和查询所有信息的操作分开。

第一条语句：查询符合条件的数据，只需要查询g.id即可

SELECT DISTINCT g.id FROM gm_game g 
    LEFT JOIN gm_cp cp ON cp.id = g.cp_id AND cp.deleted = 0 
    LEFT JOIN gm_category c ON c.id = g.category_id AND c.deleted = 0 
    LEFT JOIN gm_type t ON t.id = g.type_id AND t.deleted = 0
      WHERE g.deleted = 0 ORDER BY g.modify_time DESC LIMIT 20 ;

第二条语句：查询符合条件的详细数据，将第一条sql的结果使用in操作拼接到第二条的sql

SELECT DISTINCT g.*, cp.name AS cp_name,c.name AS category_name,t.name AS type_name FROM gm_game g
     LEFT JOIN gm_cp cp ON cp.id = g.cp_id AND cp.deleted = 0 
    LEFT JOIN gm_category c ON c.id = g.category_id AND c.deleted = 0 
    LEFT JOIN gm_type t ON t.id = g.type_id AND t.deleted = 0 
    WHERE g.deleted = 0 and g.id in(…………………) ORDER BY g.modify_time DESC ;

### 【实测效果】 ###

在SATA机器上测试，优化前大约需要50s，优化后第一条0.3s，第二条0.1s，优化后执行速度是原来的100倍以上，IO从100%降到不到1%

在SSD机器上测试，优化前大约需要7s，优化后第一条0.3s，第二条0.1s，优化后执行速度是原来的10倍以上，IO从100%降到不到1%

可以看出，优化前磁盘io是性能瓶颈，SSD的速度要比SATA明显要快，优化后磁盘不再是瓶颈，SSD和SATA性能没有差别。

### 【理论分析】 ###

MySQL在执行SQL查询时可能会用到临时表，一般情况下，用到临时表就意味着性能较低。

临时表存储

MySQL临时表分为“内存临时表”和“磁盘临时表”，其中内存临时表使用MySQL的MEMORY存储引擎，磁盘临时表使用MySQL的MyISAM存储引擎；

一般情况下，MySQL会先创建内存临时表，但内存临时表超过配置指定的值后，MySQL会将内存临时表导出到磁盘临时表；

Linux平台上缺省是/tmp目录，/tmp目录小的系统要注意啦。

**使用临时表的场景**

1.  ORDER BY子句和GROUP BY子句不同， 例如：ORDERY BY price GROUP BY name；
2.  在JOIN查询中，ORDER BY或者GROUP BY使用了不是第一个表的列 例如：SELECT \* from TableA, TableB ORDER BY TableA.price GROUP by [TableB.name][]
3.  ORDER BY中使用了DISTINCT关键字 ORDERY BY DISTINCT(price)
4.  SELECT语句中指定了SQL\_SMALL\_RESULT关键字 SQL\_SMALL\_RESULT的意思就是告诉MySQL，结果会很小，请直接使用内存临时表，不需要使用索引排序 SQL\_SMALL\_RESULT必须和GROUP BY、DISTINCT或DISTINCTROW一起使用 一般情况下，我们没有必要使用这个选项，让MySQL服务器选择即可。

**直接使用磁盘临时表的场景**

1.  表包含TEXT或者BLOB列；
2.  GROUP BY 或者 DISTINCT 子句中包含长度大于512字节的列；
3.  使用UNION或者UNION ALL时，SELECT子句中包含大于512字节的列；

**临时表相关配置**

tmp\_table\_size：指定系统创建的内存临时表最大大小； [http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html\#sysvar\_tmp\_table\_size][http_dev.mysql.com_doc_refman_5.1_en_server-system-variables.html_sysvar_tmp_table_size]

max\_heap\_table\_size: 指定用户创建的内存表的最大大小； [http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html\#sysvar\_max\_heap\_table\_size][http_dev.mysql.com_doc_refman_5.1_en_server-system-variables.html_sysvar_max_heap_table_size]

注意：最终的系统创建的内存临时表大小是取上述两个配置值的最小值。

**表的设计原则**

使用临时表一般都意味着性能比较低，特别是使用磁盘临时表，性能更慢，因此我们在实际应用中应该尽量避免临时表的使用。 常见的避免临时表的方法有：

1.  创建索引：在ORDER BY或者GROUP BY的列上创建索引；
2.  分拆很长的列：一般情况下，TEXT、BLOB，大于512字节的字符串，基本上都是为了显示信息，而不会用于查询条件， 因此表设计的时候，应该将这些列独立到另外一张表。

**SQL优化**

如果表的设计已经确定，修改比较困难，那么也可以通过优化SQL语句来减少临时表的大小，以提升SQL执行效率。

常见的优化SQL语句方法如下：

1）拆分SQL语句

临时表主要是用于排序和分组，很多业务都是要求排序后再取出详细的分页数据，这种情况下可以将排序和取出详细数据拆分成不同的SQL，以降低排序或分组时临时表的大小，提升排序和分组的效率，我们的案例就是采用这种方法。

2）优化业务，去掉排序分组等操作

有时候业务其实并不需要排序或分组，仅仅是为了好看或者阅读方便而进行了排序，例如数据导出、数据查询等操作，这种情况下去掉排序和分组对业务也没有多大影响。

如何判断使用了临时表？

使用explain查看执行计划，Extra列看到Using temporary就意味着使用了临时表。

详细信息请参考MySQL官方手册： [http://dev.mysql.com/doc/refman/5.1/en/internal-temporary-tables.html][http_dev.mysql.com_doc_refman_5.1_en_internal-temporary-tables.html]

想学习**分布式、微服务、JVM、多线程、架构、java、python**的童鞋，千万**不要**扫码，否则后果自负~

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbnpoaXFpYW5nMDMxNg_size_16_color_FFFFFF_t_70][]

**林老师带你学编程**：[https://wolzq.com][https_wolzq.com]

[image]: /images/20220121/303f047c72774a50a37c661338f893d4.png
[TableB.name]: http://tableb.name/
[http_dev.mysql.com_doc_refman_5.1_en_server-system-variables.html_sysvar_tmp_table_size]: http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_tmp_table_size
[http_dev.mysql.com_doc_refman_5.1_en_server-system-variables.html_sysvar_max_heap_table_size]: http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_max_heap_table_size
[http_dev.mysql.com_doc_refman_5.1_en_internal-temporary-tables.html]: http://dev.mysql.com/doc/refman/5.1/en/internal-temporary-tables.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpbnpoaXFpYW5nMDMxNg_size_16_color_FFFFFF_t_70]: /images/20220121/af26e339daf14a288aee3dd7f617894a.png
[https_wolzq.com]: https://wolzq.com/