sql临时表优化经验
【问题现象】
线上mysql/ target=_blank class=infotextkey>mysql数据库爆出一个慢查询，DBA观察发现，查询时服务器IO飙升，IO占用率达到100%， 执行时间长达7s左右。
sql语句：
【问题分析】
使用explain查看执行计划，结果如下：
这条sql语句的问题其实还是比较明显的：
查询了大量数据(包括数据条数、以及g.* )，然后使用临时表order by，但最终又只返回了20条数据。
DBA观察到的IO高，是因为sql语句生成了一个巨大的临时表，内存放不下，于是全部拷贝到磁盘，导致IO飙升。
【优化方案】
优化的总体思路是拆分sql，将排序操作和查询所有信息的操作分开。
第一条语句：查询符合条件的数据，只需要查询g.id即可
第二条语句：查询符合条件的详细数据，将第一条sql的结果使用in操作拼接到第二条的sql
【实测效果】
在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服务器选择即可。