问题

最近在调试一条查询耗时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分析结果 有所删减

优化前后的变化有四点:1、不再Using temporary和Using filesort;2、表的查询顺寻变了;3、查询扫描的rows增加了;4、查询时间由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

书愤

陆游

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

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

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

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

MySQL STRAIGHT_JOIN的更多相关文章

  1. Mysql 多表查询

    文章转载的:http://www.cnblogs.com/BeginMan/p/3754322.html 一.Join语法概述 join 用于多表中字段之间的联系,语法如下: ... FROM tab ...

  2. (转)MySQL join语法解析与性能分析

    文章转载的:http://www.cnblogs.com/BeginMan/p/3754322.html 一.join语法概述 join用于多表中字段之间的联系,语法如下: ... FROM tabl ...

  3. mysql的join操作

    一.Join语法概述 join 用于多表中字段之间的联系,语法如下: ... FROM table1 INNER|LEFT|RIGHT JOIN table2 ON conditiona table1 ...

  4. mysql 关于join的总结

    本文地址:http://www.cnblogs.com/qiaoyihang/p/6401280.html mysql不支持Full join,不过可以通过UNION 关键字来合并 LEFT JOIN ...

  5. [转]Mysql Join语法解析与性能分析

    转自:http://www.cnblogs.com/BeginMan/p/3754322.html 一.Join语法概述 join 用于多表中字段之间的联系,语法如下: ... FROM table1 ...

  6. MySQL- -Join语法解析与性能分析

    Mysql Join语法解析与性能分析 一.Join语法概述 join 用于多表中字段之间的联系,语法如下: ... FROM table1 INNER|LEFT|RIGHT JOIN table2 ...

  7. MySQL优化的奇技淫巧之STRAIGHT_JOIN

    原文地址:http://huoding.com/2013/06/04/261 问题 通过「SHOW FULL PROCESSLIST」语句很容易就能查到问题SQL,如下: SELECT post.* ...

  8. MySQL HINT:Straight_JOIN

    来自生产环境的朋友.可能都会碰到:          原本运行良好的查询语句,过了一段时间后,可能会突然变得很糟糕     一个很大可能的原因就是数据分布情况发生了变化     从而导致MySQL优化 ...

  9. 20170103简单解析MySQL查询优化器工作原理

    转自博客http://www.cnblogs.com/hellohell/p/5718238.html 感谢楼主的贡献 查询优化器的任务是发现执行SQL查询的最佳方案.大多数查询优化器,包括MySQL ...

随机推荐

  1. 天底下最简单的QT画图板,就一个类,60行代码

    简单直观.但是我有个问题是,这实际上不是在绘制直线,而是几千几万个超级短的“直线”,这样会不会效率很低呢? 注意,每次绘制的时候,需要一支笔,这支笔需要设置颜色和宽度(就像我们平时写字也要稍微挑一下笔 ...

  2. VA自动补全QT

    发现用了一下,VA不能把QT的东西进行代码自动补全.于是要动下小手脚. 1.在Windows系统环境变量下增加 QTDIR = 你QT的安装目录. 2启动VS->工具->选项->项目 ...

  3. 【HDOJ】1497 Simple Library Management System

    链表. #include <cstdio> #include <cstring> #include <cstdlib> #define MAXM 1001 #def ...

  4. redis 网络流程图 <一>

    本来一直想好好读下redis源码.可是每次读了一点就不读了.  主要是没坚持每天都读. 隔几天看.就忘记前面的流程.就越来越不想看了.  很是蛋疼.这个还是要坚持读完的.打算这段时间都源码的时候.都大 ...

  5. N - Picture - poj 1177(扫描线求周长)

    题意:求周长的,把矩形先进行融合后的周长,包括内周长 分析:刚看的时候感觉会跟棘手,让人无从下手,不过学过扫描线之后相信就很简单了吧(扫描线的模板- -),还是不说了,下面是一精确图,可以拿来调试数据 ...

  6. memcached几个easy被忽略但很实用的命令

    一.CAS和GETS Memcached从1.2.4版本号新增CAS(Check and Set)协议,用于处理同一个ITEM(key-value)被多个session更新改动时的数据一致性问题. 如 ...

  7. HDU2841 Visible Trees (容斥原理)

    主题链接:http://acm.hdu.edu.cn/showproblem.php?pid=2841 题意: 一个人在(0,0)点,然后前面有一个m*n的格子 ,每一个格子的节点上有一棵树.问这个人 ...

  8. gcc -L -l的使用

    -l参数就是用来指定程序要链接的库,-l参数紧接着就是库名,那么库名跟真正的库文件名有什么关系呢?就拿数学库来说,他的库名是m,他的库文件名是libm.so,很容易看出,把库文件名的头lib和尾.so ...

  9. C#文件的拆分与合并操作示例

    C#文件的拆分与合并操作示例代码. 全局变量定义 ;//文件大小 //拆分.合并的文件数 int count; FileInfo splitFile; string splitFliePath; Fi ...

  10. Node.js开发环境介绍-调试工具

    1)WebStorm 断点调试,单步执行 2)nodemon 监听文件变更,自动重启 3)node-inspector 基于浏览器调试nodejs 4)Chrome Developer Tools 基 ...