【转帖】【性能提升神器】STRAIGHT_JOIN

性能,提升,神器,straight,join · 浏览次数 : 0

小编点评

## STRAIGHT_JOIN 的用法: STRAIGHT_JOIN 和 JOIN 的主要区别在于: * STRAIGHT_JOIN 将 **左表** 总是读取完毕后,才与 **右表** 进行连接。 * JOIN 默认将 **左表** 读取完毕后,才与 **右表** 进行连接。 这使得 STRAIGHT_JOIN 在某些情况下可以显著提高执行效率,因为它能使优化器更能根据表的顺序来执行查询。 **示例:** ```sql select t1.* from Table1 t1 inner join Table2 t2 on t1.CommonID = t2.CommonID where t1.FilterID = 1; ``` 这个查询可能执行很长时间,因为 `Table1` 表中的索引可能无法帮助优化器进行索引扫描。 **使用 STRAIGHT_JOIN 的场景:** * 当连接条件限制了 **左表** 的记录数量时。 * 当需要对 **左表** 中的所有记录进行处理时。 **注意:** STRAIGHT_JOIN 只能用于 **inner join**。

正文

 

今天给大家下另一个性能提升神器-STRAIGHT_JOIN,在数据量大的联表查询中灵活运用的话,能大大缩短查询时间。

首先来解释下STRAIGHT_JOIN到底是用做什么的:

STRAIGHT_JOIN is similar to JOIN, except that the left table is always read before the right table. 
This can be used for those (few) cases for which the join optimizer puts the tables in the wrong order.

意思就是说STRAIGHT_JOIN功能同join类似,但能让左边的表来驱动右边的表,能改表优化器对于联表查询的执行顺序。

接下来我们举个例子进行大致的分析:

 

复制代码
select t1.*
from Table1 t1
inner join Table2 t2
on t1.CommonID = t2.CommonID
where t1.FilterID = 1
复制代码

 

以上sql大数据量下执行需要30s,是不是很奇怪?明明Table1表的FilterID字段建了索引啊,Table1和Table2的CommonID也建了索引啊。通过explain来分析,你会发现执行计划中表的执行顺序是Table2->Table1。这个时候要略微介绍下驱动表的概念,mysql中指定了连接条件时,满足查询条件的记录行数少的表为驱动表;如未指定查询条件,则扫描行数少的为驱动表。mysql优化器就是这么粗暴以小表驱动大表的方式来决定执行顺序的

但如下sql的执行时间都少于1s:

select t1.*
from Table1 t1
where t1.FilterID = 1

select t1.*
from Table1 t1
inner join Table2 t2
on t1.CommonID = t2.CommonID

 这个时候STRAIGHT_JOIN就派上用场,我们对sql进行改造如下:

复制代码
select t1.*
from Table1 t1
STRAIGHT_JOIN  Table2 t2
on t1.CommonID = t2.CommonID
where t1.FilterID = 1
复制代码

用explain进行分析,发现执行顺序为Table1->Table2,这时就由Table1来作为驱动表了,Table1中相应的索引也就用上了,执行时间竟然低于1s了。

分析到这里,必须要重点说下:

  • STRAIGHT_JOIN只适用于inner join,并不使用与left join,right join。(因为left join,right join已经代表指定了表的执行顺序)
  • 尽可能让优化器去判断,因为大部分情况下mysql优化器是比人要聪明的。使用STRAIGHT_JOIN一定要慎重,因为啊部分情况下认为指定的执行顺序并不一定会比优化引擎要靠谱。

 

扩展阅读:

https://stackoverflow.com/questions/512294/when-to-use-straight-join-with-mysql

https://stackoverflow.com/questions/5818837/why-does-straight-join-so-drastically-improve-this-query-and-what-does-it-mean

https://dev.mysql.com/doc/refman/8.0/en/join.html

与【转帖】【性能提升神器】STRAIGHT_JOIN相似的内容:

【转帖】【性能提升神器】STRAIGHT_JOIN

今天给大家下另一个性能提升神器-STRAIGHT_JOIN,在数据量大的联表查询中灵活运用的话,能大大缩短查询时间。 首先来解释下STRAIGHT_JOIN到底是用做什么的: STRAIGHT_JOIN is similar to JOIN, except that the left table i

[转帖]7 个使用 bcc/BPF 的性能分析神器

https://t.cj.sina.com.cn/articles/view/1772191555/69a17f430190029mf 在 Linux 中出现的一种新技术能够为系统管理员和开发者提供大量用于性能分析和故障排除的新工具和仪表盘。它被称为增强的伯克利数据包过滤器(eBPF,或 BPF),

[转帖]神秘的backlog参数与TCP连接队列

https://www.cnblogs.com/codelogs/p/16060820.html 简介# 这要从一次压测项目说起,那是我们公司的系统与另几家同行公司的系统做性能比拼,性能数据会直接影响项目中标,因此压力非常大。 当时甲方给大家提供了17台服务器供系统部署,并使用LoadRunner对

[转帖]性能最高提升36%!基于阿里云倚天实例的Redis性能测试验证

性能最高提升36%!基于阿里云倚天实例的Redis性能测试验证 https://aijishu.com/a/1060000000376643 云计算Benchmark性能优化Arm 处理器Alibaba 本文转载自阿里云开发者社区。https://developer.aliyun.com/... 简

[转帖]JVM性能提升50%,聊一聊背后的秘密武器Alibaba Dragonwell

https://zhuanlan.zhihu.com/p/453437019 今年四月五日,阿里云开放了新一代ECS实例的邀测[1],Alibaba Dragonwell也在新ECS上进行了极致的优化。相比于之前的dragonwell_11.0.8.3版本,即将发布的dragonwell_11.0.

[转帖]Linux性能优化(十二)——CPU性能调优

Linux性能优化(十二)——CPU性能调优 https://blog.51cto.com/u_9291927/2594259 一、应用程序优化 (1)编译器优化。适当开启编译器优化选项,在编译阶段提升性能。gcc提供优化选项-On会自动对应用程序的代码进行优化。(2)算法优化。使用复杂度更低的算法

[转帖]实现 10 倍应用性能提升的 10 个技巧

https://my.oschina.net/u/5246775/blog/5981861 Web 应用性能优化迫在眉睫。线上经济活动份额不断增长,发达世界的互联网经济已占经济总量的 5% 以上(请参见下文的互联网统计数据来源)。在这个始终在线、超级互联的现代世界,用户的期望已经今非昔比。如果您的网

[转帖]通过硬件计数器,将性能提升3倍之旅

https://www.cnblogs.com/charlieroro/p/16880090.html 翻译自:Seeing through hardware counters: a journey to threefold performance increase 本文通过对CPU层面的代码挖掘,

[转帖]10+倍性能提升全过程

https://plantegg.github.io/2018/01/23/10+%E5%80%8D%E6%80%A7%E8%83%BD%E6%8F%90%E5%8D%87%E5%85%A8%E8%BF%87%E7%A8%8B/ 背景说明 2016年的双11在淘宝上买买买的时候,天猫和优酷土豆一起做

[转帖]在 TiDB 中正确使用索引,性能提升 666 倍

https://tidb.net/book/tidb-monthly/2022/2022-04/usercase/index-666 背景​ 最近在给一个物流系统做TiDB POC测试,这个系统是基于MySQL开发的,本次投入测试的业务数据大概10个库约900张表,最大单表6千多万行。 这个规模不算