实例1：优化临时表使用，SQL语句性能提升100倍

实例2：mysql优化案例分析

 

实例1：优化临时表使用，SQL语句性能提升100倍

【问题现象】

线上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 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 ;

【问题分析】

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

这条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

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

 

实例2：mysql优化案例分析

 

 sql优化一般分为两类，一类是sql本身的优化，如何走到合适的索引，如何减少排序，减少逻辑读；

 另一类是sql本身没有优化余地，需要结合业务场景进行优化。即在满足业务需求的情况下对sql进行改造，已提高sql执行速度，减少响应时间。

 

例子1：

SELECT ID FROM SENDLOG WHERE TO_DAYS(NOW())-TO_DAYS(GMT_CREATE) > 7;

问题：对索引列GMT_CREATE进行了运算，无法使用索引

MySQL优化分析工具 mysql优化实例_sql

优化后sql：

select id from sendlog where gmt_create < now() - 7

MySQL优化分析工具 mysql优化实例_SQL_02

 

例子2：

SELECT * FROM SENDLOG where result = 1 and gmt_create > '2013-10-29 12:40:44' limit 2000;

MySQL优化分析工具 mysql优化实例_sql_03

问题：result列含有索引，但mysql执行计划没有用到。

分析：result类型为char，传递的值1为整型，数据类型不一致，导致没法用索引，对于时间类型gmt_create > '2013-10-29 12:40:44'，可以直接使用。

优化后sql：

SELECT * FROM SENDLOG where result = '1' and gmt_create > '2013-10-29 12:40:44' limit 2000;

MySQL优化分析工具 mysql优化实例_MySQL优化分析工具_04

例子3：

场景：获取某个卖家未读的消息。

select count(*) from mc_msg where receiver='sun098' and status='UNREAD' and title is not null;
问题：有时候db负载飙高，sql响应时间变慢。

分析：导致db负载飙高的原因是多个大卖家并发查询的时，cpu和逻辑读增加，load飙高。由于receiver,status已有索引，sql本身已经没有优化空间，了解业务后发现其实业务不需要精确值，如果大于99条，页面就直接显示为99+

优化后sql：

select count(*) from (select id from mc_msg where receiver='sun098' and status='UNREAD' and title is not null limit 100) a;

例子4：

场景：查看历史订单留言记录，未读留言的放在前面，已读的放在后面，并且按时间递减排序

select * from(
select ID,GMT_CREATE,GMT_MODIFIED,SENDER_ALI_ID,RECEIVER_ALI_ID,UNREAD_COUNT,STATUS,LAST_MESSAGE_ID,RELATION_ID,SELLER_ADMIN_SEQ,IS_READ 
from message_relation_sender
WHERE SENDER_ALI_ID = 119545671  and UNREAD_COUNT > 0 
order by LAST_MESSAGE_ID desc) m 
union all 
select * from(
select ID,GMT_CREATE,GMT_MODIFIED,SENDER_ALI_ID,RECEIVER_ALI_ID,UNREAD_COUNT,STATUS,LAST_MESSAGE_ID,RELATION_ID,SELLER_ADMIN_SEQ,IS_READ from message_relation_sender
WHERE SENDER_ALI_ID = 119545671  and UNREAD_COUNT = 0 
order by LAST_MESSAGE_ID desc) n limit 5000,15;

 

分析：

(1)unread_count表示未读的订单留言记录数目；

(2)第一个子查询获取未读留言记录，第二子查询获取已读留言记录；

(3)LAST_MESSAGE_ID 递增，最新的订单留言，LAST_MESSAGE_ID最大。

(4)limit 5000,15是分页查询

这里使用union all，主要特点在于union all 不对结果集排序，直接合并，达到了“未读留言的放在前面，已读的放在后面”的效果，但同时也造成了两次扫描索引的结果，每个子查询都需要排序；而且union all还会产生临时表，执行代价会更大。

 

优化：

这里看到unread_count实际值对这个查询没有实际意义，我们只需要区分已读和未读即可。由于sql本身已经没有优化余地，考虑对表结构进行修改，加一个字段is_read，表示已读和未读。is_read=2表示未读；is_read=1表示已读。通过组合索引(SENDER_ALI_ID,is_read, LAST_MESSAGE_ID),既可以完成过滤，还可以完成排序。

 

优化后sql：

select ID,GMT_CREATE,GMT_MODIFIED,SENDER_ALI_ID,RECEIVER_ALI_ID,UNREAD_COUNT,STATUS,LAST_MESSAGE_ID,RELATION_ID,SELLER_ADMIN_SEQ,IS_READ from message_relation_sender
where SENDER_ALI_ID = 119545671  order by is_read desc, LAST_MESSAGE_ID desc limit 5000,15

 

第二次优化：

由于索引不包含所有的返回字段，因此需要回表，而mysql对于limit 5000,15的查询却需要返回5015次，这种无效的返回很影响查询效率。

分页的优化写法：

select t1.ID,GMT_CREATE,GMT_MODIFIED,SENDER_ALI_ID,RECEIVER_ALI_ID,UNREAD_COUNT,STATUS,LAST_MESSAGE_ID,RELATION_ID,SELLER_ADMIN_SEQ,IS_READ from message_relation_sender t1,
(select id 
 from message_relation_sender
 where SENDER_ALI_ID = 119545671 order by is_read desc, LAST_MESSAGE_ID desc limit 5000,15
)t2 where t1.id = t2.id

 

分析：由于id是主键，不需要回表，通过连接查询，最终只需要15次回表即可。