在MySQL中使用STRAIGHT_JOIN的教程

 更新时间:2015年05月30日 12:11:21   投稿:goldensun  
这篇文章主要介绍了在MySQL中使用STRAIGHT_JOIN的教程,包括使用STRAIGHT_JOIN进行一些性能上的优化的技巧,需要的朋友可以参考下

问题

   通过「SHOW FULL PROCESSLIST」语句很容易就能查到问题SQL,如下:

SELECT post.*
FROM post
INNER JOIN post_tag ON post.id = post_tag.post_id
WHERE post.status = 1 AND post_tag.tag_id = 123
ORDER BY post.created DESC
LIMIT 100

   说明:因为post和tag是多对多的关系,所以存在一个关联表post_tag。

   试着用EXPLAIN查询一下SQL执行计划(篇幅所限,结果有删减):

+----------+---------+-------+-----------------------------+
| table  | key   | rows | Extra            |
+----------+---------+-------+-----------------------------+
| post_tag | tag_id | 71220 | Using where; Using filesort |
| post   | PRIMARY |   1 | Using where         |
+----------+---------+-------+-----------------------------+

   下面给出优化后的SQL,唯一的变化就是把连接方式改成了「STRAIGHT_JOIN」:

SELECT post.*
FROM post
STRAIGHT_JOIN post_tag ON post.id = post_tag.post_id
WHERE post.status = 1 AND post_tag.tag_id = 123
ORDER BY post.created DESC
LIMIT 100

   试着用EXPLAIN查询一下SQL执行计划(篇幅所限,结果有删减):

+----------+----------------+--------+-------------+
| table  | key      | rows  | Extra    |
+----------+----------------+--------+-------------+
| post   | status_created | 119340 | Using where |
| post_tag | post_id    |   1 | Using where |
+----------+----------------+--------+-------------+

   对比优化前后两次EXPLAIN的结果来看,优化后的SQL虽然「rows」更大了,但是没有了「Using filesort」,综合来看,性能依然得到了提升。
解释

   对第一条SQL而言,为什么MySQL优化器选择了一个耗时的执行方案?对第二条SQL而言,为什么把连接方式改成STRAIGHT_JOIN之后就提升了性能?

   这一切还得从MySQL对多表连接的处理方式说起,首先要确定以谁为驱动表,也就是说以哪个表为基准,在处理此类问题时,MySQL优化器采用了简单粗暴的解决方法:哪个表的结果集小,就以哪个表为驱动表,通常这都是最佳选择。

   说明:在EXPLAIN结果中,第一行出现的表就是驱动表。

   继续post连接post_tag的例子,MySQL优化器有如下两个选择,分别是:

  1.     以post为驱动表,通过status_created索引过滤,结果集119340行
  2.     以post_tag为驱动表,通过tag_id索引过滤,结果集71220行

       显而易见,post_tag过滤的结果集更小,所以MySQL优化器选择它作为驱动表,可悲催的是我们还需要以post表中的created字段来排序,也就是说排序字段不在驱动表里,于是乎不可避免的出现了「Using filesort」,从而导致慢查询。

       知道了来龙去脉,优化起来就容易了。头等大事是务必保证排序字段在驱动表中,所以必须以post是驱动表,于是乎「STRAIGHT_JOIN」就成了答案,它强制了连接顺序。

       …

       不过我总觉得「STRAIGHT_JOIN」这种非标准的语法属于奇技淫巧的范畴,能不用尽量不用,毕竟多数情况下,MySQL优化器都能做出正确的选择。

相关文章

  • mysql ndb集群备份数据库和还原数据库的方法

    mysql ndb集群备份数据库和还原数据库的方法

    中午刚刚弄明白了MYSQL集群的备份与恢复。写下来,以后就不用为这个问题浪费时间了
    2011-12-12
  • 利用JuiceFS使MySQL 备份验证性能提升 10 倍

    利用JuiceFS使MySQL 备份验证性能提升 10 倍

    这篇文章主要介绍了如何让 MySQL 备份验证性能提升 10 倍,JuiceFS 非常适合用来做 MySQL 物理备份,通过不断调整 XtraBackup 的参数和 JuiceFS 的挂载参数,在一个小时内将时间缩短到原先的 1/10,下文一起来看相关内容的详细介绍吧
    2022-03-03
  • MySQL开启慢查询日志log-slow-queries的方法

    MySQL开启慢查询日志log-slow-queries的方法

    MySQL中提供了一个慢查询的日志记录功能,可以把查询SQL语句时间大于多少秒的语句写入慢查询日志,日常维护中可以通过慢查询日志的记录信息快速准确地判断问题所在
    2016-05-05
  • MySQL开放远程连接权限的两种方法

    MySQL开放远程连接权限的两种方法

    在我们使用mysql数据库时,有时我们的程序与数据库不在同一机器上,这时我们需要远程访问数据库,下面这篇文章主要给大家介绍了关于MySQL开放远程连接权限的两种方法,需要的朋友可以参考下
    2022-06-06
  • MySQL文本文件导入及批处理模式应用说明

    MySQL文本文件导入及批处理模式应用说明

    MySQL文本文件导入及批处理模式应用说明,需要的朋友可以参考下。
    2011-09-09
  • 安装mysql出错”A Windows service with the name MySQL already exists.“如何解决

    安装mysql出错”A Windows service with the name MySQL already exis

    这篇文章主要介绍了安装mysql出错”A Windows service with the name MySQL already exists.“如何解决的相关资料,在日常项目中此问题比较多见,特此把解决办法分享给大家,供大家参考
    2016-05-05
  • MySQL on k8s 云原生环境部署

    MySQL on k8s 云原生环境部署

    这篇文章主要为大家介绍了MySQL on k8s 云原生环境部署实现过程详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2022-09-09
  • MySQL批量修改表及表内字段排序规则举例详解

    MySQL批量修改表及表内字段排序规则举例详解

    在MySQL中字段排序规则(也称为字符集和排序规则)用于确定如何比较和排序字符串,下面这篇文章主要给大家介绍了关于MySQL批量修改表及表内字段排序规则的相关资料,需要的朋友可以参考下
    2024-05-05
  • MySQL的核心查询语句详解

    MySQL的核心查询语句详解

    这篇文章主要介绍了MySQL的核心查询语句详解,MySQL是一个流行的关系型数据库管理系统,可用于存储、管理和检索数据。它是一个独立的数据库服务器软件,可安装在计算机或服务器上,需要的朋友可以参考下
    2023-07-07
  • mysql limit分页优化方法分享

    mysql limit分页优化方法分享

    MySQL的优化是非常重要的。其他最常用也最需要优化的就是limit。MySQL的limit给分页带来了极大的方便,但数据量一大的时候,limit的性能就急剧下降。
    2011-04-04

最新评论