MySQL STRAIGHT_JOIN

问题

最近在调试一条查询耗时5s多的sql语句，这条sql语句用到了多表关联（inner join），按时间字段排序（order by），时间字段上已经建立了索引（索引名IDX_published_at）。经过explain分析发现，时间字段上的索引没用上（Using temporary和Using filesort），问题很明显，可是缘由是什么呢？

SELECT * FROM news n0_ inner join news_translations n1_ ON n0_.id = n1_.translatable_id inner join channels_news c3_ ON n0_.id = c3_.news_id 
WHERE 
((n0_.unpublished_at IS NOT NULL AND (CURRENT_TIMESTAMP >= n0_.published_at AND CURRENT_TIMESTAMP < n0_.unpublished_at)) OR (CURRENT_TIMESTAMP >= n0_.published_at AND n0_.unpublished_at IS NULL))
AND (n0_.status = 1 AND n0_.content_type_id = 1) AND n0_.id NOT IN (510466, 510433, 24, 11, 10, 9, 4) 
AND n0_.home_position_id IS NULL 
AND 
n1_.locale = 'zh_CN' 
AND 
c3_.channel_id = 1 
ORDER BY n0_.published_at DESC 
LIMIT 5 ;

优化前sql语句

+-------+--------+-------------------------------+--------+-----------------------------------------------------------+
| table | type   | key                           | rows   | Extra                                                     |
+-------+--------+-------------------------------+--------+-----------------------------------------------------------+
| c3_   | ref    | IDX_87B9249E72F5A1AA          | 161590 | Using where; Using index; Using temporary; Using filesort |
| n0_   | eq_ref | PRIMARY                       |      1 | Using where                                               |
| n1_   | ref    | UNIQ_20FDB3302C2AC5D34180C698 |      1 | Using where                                               |
+-------+--------+-------------------------------+--------+-----------------------------------------------------------+

explain分析结果 有所删减

通过一轮折腾的优化，获得了下面的sql语句

SELECT * FROM news n0_ STRAIGHT_JOIN news_translations n1_ ON n0_.id = n1_.translatable_id STRAIGHT_JOIN channels_news c3_ ON n0_.id = c3_.news_id 
WHERE 
((n0_.unpublished_at IS NOT NULL AND (CURRENT_TIMESTAMP >= n0_.published_at AND CURRENT_TIMESTAMP < n0_.unpublished_at)) OR (CURRENT_TIMESTAMP >= n0_.published_at AND n0_.unpublished_at IS NULL))
AND (n0_.status = 1 AND n0_.content_type_id = 1) AND n0_.id NOT IN (510466, 510433, 24, 11, 10, 9, 4) 
AND n0_.home_position_id IS NULL 
AND 
n1_.locale = 'zh_CN' 
AND 
c3_.channel_id = 1 
ORDER BY n0_.published_at DESC 
LIMIT 5 ;

优化后sql语句

+-------+--------+-------------------------------+--------+--------------------------+
| table | type   | key                           | rows   | Extra                    |
+-------+--------+-------------------------------+--------+--------------------------+
| n0_   | range  | IDX_published_at              | 255440 | Using where              |
| n1_   | ref    | UNIQ_20FDB3302C2AC5D34180C698 |      1 | Using where              |
| c3_   | eq_ref | PRIMARY                       |      1 | Using where; Using index |
+-------+--------+-------------------------------+--------+--------------------------+

优化后explain分析结果 有所删减

优化先后的变化有四点：一、再也不Using temporary和Using filesort；二、表的查询顺寻变了；三、查询扫描的rows增长了；四、查询时间由5s降到了0.02s。

缘由分析

优化先后出现的四点变化，性能显著提高，须要从mysql的关联的链接处理提及。

如下参考《高性能MySQL》

1）优化前的sql语句以channels_news为第一个关联表，找到161590条记录；2）优化后的sql语句以news表为第一关联表，找到255440条记录，比第一条sql语句查找多了9W多条。所以，优化前的sql语句的关联顺序是MySQL优化器的选择，可让查询进行更小的嵌套循环和回溯操做。MySQL经过选择合适的关联顺序来让查询执行的成本尽量低，从新定义关联的顺序是优化器很重要的一部分功能。不过有时候，优化器给出的并非最优的关联顺序。这时能够使用STRAIGHT_JOIN关键字重写查询，让优化器按照你认为的最优关联顺序执行。

从优化后的explain分析结果看出，news是驱动表，结果以news表的published_at字段进行排序，因此用上了索引，避免了Using temporary和Using filesort，天然而然的，查询时间也降下来了。正如前面说的，mysql的优化器经过粗暴的小表驱动大表来选择链接的顺序，第一条sql语句扫描了161590行，第二条sql语句扫描了255440行，优化后的sql语句扫描的行数增长了。

结语

结案陈词：形成此次sql语句查询耗时5s的缘由是，sql语句order by的字段不在mysql的优化器选在驱动表上，因此致使此次关联查询排序字段上的索引没有被使用。所以，经过使用STRAIGHT_JOIN来强制制定关联查询的表顺序，以达到优化的目的。可是，有时候咱们人为地指定顺序不必定比mysql的优化引擎准确，因此在使用STRAIGHT_JOIN的时候三思然后行。

本文连接：http://www.hcoding.com/?p=211

原创文章，转载请注明：JC&hcoding.com

书愤

陆游

早岁那知世事艰，中原北望气如山。

楼船夜雪瓜洲渡，铁马秋风大散关。

塞上长城空自许，镜中衰鬓已先斑。

出师一表真名世，千载谁堪伯仲间。