其他分享
首页 > 其他分享> > Join查询联表的数量最大到底不要超过多少,有人说5,有人说6??

Join查询联表的数量最大到底不要超过多少,有人说5,有人说6??

作者:互联网

前言

从今天开始,小怪将使用CSDN社区作为MySQL案例的应用场景,详细剖析MySQL的实现细节。

相信博友们都知道CSDN社区个人主页上有一个“关注了”和“关注者”的功能,尤其是“关注者”功能,当你看到消息提醒,又有人关注你啦,你可能会点进关注者列表瞅瞅:咦,今天又有哪位大佬关注我啦!有点小激动,哈哈哈!
今天小怪就以“关注者”这个功能为例,看看我们是怎么用SQL实现该功能的,语句背后的执行原理又是怎样的?
我们先来看看如何用SQL实现“关注者”功能:

SELECT user.user_name, user.avatar, user.position, user.company FROM user LEFT JOIN t_user_relation ON user.user_id = t_user_relation.follow_user_id WHERE t_user_relation.followed_user_id = 10008

上面这条SQL表示查询user_id=10008的关注列表,SELECT字段包含用户名user_name、头像avatar、职位position和公司company,where条件的字段为followed_user_id,即被关注者用户id,从上面的语句看,这是一个left join查询,当然因为“关注者”列表这个功能是一个在线功能,一般我们通过先查t_user_relation表,根据被关注者用户id得到关注者用户id,后拿关注者用户id查user表来完成这个功能。不过,这里,我只是拿这个案例来开启今天联表查询这个主题。

在《Join查询深度优化 - 不为人知的新方法》一文中讲解了Join查询的几种策略,通过这篇文章,你应该对Join查询的基本过程有了一定的了解,那么,结合上面这个案例,那么,只要让MySQL使用Index Nested-Loop Join策略来执行这条语句,性能上还是可以有所保证的,因为查询能命中索引。

但是,这个案例中的SQL只关联了两张表user和t_user_relation,如果在有些场景下,比如,报表查询,由于跨业务域的原因,这时候可能不得不关联5张、6张、10张甚至更多的表来获取想要的数据,那么,此时的联表查询可能就会变得很慢,那么,我到底在语句中关联几张表才能保证语句执行不至于慢得离谱呢?

在《MySQL为什么选择执行计划A而不选择B(上)》和《MySQL为什么选择执行计划A而不选择B(下)》两篇文章中,详细讲解了基于MySQL成本模型的优化策略:MySQL会针对多个潜在的QEP(查询执行计划),比较其执行成本,最后选择执行成本最低的来执行语句。

而联表查询,比如上面的案例,既可以用user表来驱动t_user_relation表,也可以反过来,用t_user_relation表来驱动user表,那么,MySQL同样会基于成本模型,比较这两种方案的执行成本,最后,选择成本最低的来执行语句,即选择最低成本的驱动关系

既然MySQL是通过比较不同的驱动关系的执行成本来选择驱动表的,那么,表关联越多,意味着各种驱动关系组合就越多(最坏的情况有2的n次方-1种组合,n为关联表数量),比较各种组合的执行成本的代价也就越高,进而相应的查询语句执行就会变慢。

既然语句执行慢的原因之一是花在了驱动关系的成本分析上,那么,我们就来看一下这个驱动关系成本分析的过程是什么样的?

在讲解成本分析的过程之前,我们先来看下成本分析相关的几个核心结构,因此,在这里,我以《导读》中的语句为例来讲解这些结构:

在这里插入图片描述

Join

一条语句的结构解析后就会存放在Join这个结构里,包含select列、from表、where、groupby、orderby等信息。

但是,如果我把语句改成这样:

SELECT user.user_name, user.avatar, user.position, user.company FROM user LEFT JOIN t_user_relation ON user.user_id = t_user_relation.follow_user_id WHERE user.user_id = 10008

那么,我们发现where条件的字段使用左表user的字段user_id,因此,使用该条件查询t_user_relation表时依赖user表的user_id字段,因此,这时候,上图中第二个JOIN_TAB中的dependent就是user表,表示t_user_relation表查询依赖user表中的字段。

驱动表选择

讲解完核心数据结构之后,你可能有个疑问:既然st_position中的JOIN_TAB和JOIN_TAB数组中的JOIN_TAB的关系是1:1,为什么MySQL不把st_position放到JOIN_TAB数组中的JOIN_TAB中呢?先别急,我们先来看下这张图:

在这里插入图片描述
有没有发现,这不就是一个图的深度遍历嘛!没错!

t1 -> t2 -> t4:表示依次查询t1、t2和t4表:

分析t1,得到t1成本为2.6,将该成本带入t2,即图中第一个红色箭头上的2.6。
分析t2,得到t2成本为9.6,带入成本2.6 + t2成本9.6,得到t1 -> t2总成本12.2。将12.2带入t4。即图中第二个红色箭头上的12.2。

分析t4,得到t4成本为1.6,带入成本12.2 + t4成本1.6,得到t1 -> t2 -> t4总成本13.8。

t1 -> t3 -> t4:表示依次查询t1、t3和t4表,同理,得到t1 -> t3 -> t4总成本12.8。

我们拿这个过程对比上面的Join结构,是不是发现,刚好st_position这个结构可以描述上面这个深度遍历过程中,两个节点的关系,因此,MySQL单独设计了st_position来表示执行计划遍历路径中两张表的成本关系。其中,st_position中的prefix_cost就是当前节点之前(包含当前节点)的总成本,read_cost就是当前节点的查询成本。

在讲完核心结构之后,我们可以看看MySQL是如何比较驱动关系的成本的,上面我提到了深度遍历,聪明的小伙伴已经猜到了,没错!MySQL在比较不同的驱动关系成本的时候,也使用了深度遍历,这种遍历方式在算法上叫做贪婪搜索。因此,《前言》中的语句,其贪婪搜索的过程就变成这样:

在这里插入图片描述
如上图,MySQL分别计算了user表驱动t_user_relation表和t_user_relation表驱动user表的成本:

  1. user -> t_user_relation:user表查询成本为2.6,t_user_relation查询成本为9.6,因此,总成本为2.6 + 9.6 = 12.2。
  2. t_user_relation -> user:t_user_relation表查询成本为2.0127,user表查询成本为6,因此,总成本为2.0127 + 6 = 8.0127。

那么,现在我们了解了MySQL比较驱动关系成本的过程,回到关联表过多,导致查询变慢的问题,我们知道如果关联表很多,那么,MySQL处理查询语句时,不得不做更多的表顺序组合,对各种组合进行贪婪搜索,来比较它们的成本。这对MySQL而言,势必影响查询的性能。

剪枝调优

好在MySQL给我提供了参数,可以调整这个变量的值。prune_level变量默认为1,我们只需执行下面的命令,就可以将prune_level变量置成0,表示关闭剪枝功能。

set optimizer_prune_level = 0;

遍历深度调优

MySQL在实现贪婪搜索时,使用递归的方法做深度遍历,那么,如果联表的数量非常大,递归调用产生的临时内存空间就会非常大,对于内存敏感的MySQL而言,是不太能接受的,因此,MySQL对遍历的最大深度做了限制,默认为62。

随之而来的问题出现了,如果连接的表数为100,那么,以一张表开始深度遍历其他表,就会触达MySQL的最大深度限制,我们可以想象,这个O(62)的空间复杂度对查询性能的影响是巨大的,因此,我们肯定希望可以调小这个遍历最大深度的阈值。

那么,我们将这个阈值调整到多少合适呢?MySQL很聪明,它给我们提供了一个阈值0,这表示什么含义呢?0表示MySQL自身给我们动态计算了最大遍历深度,计算规则如下:

  1. 如果表数量小于等于7,那么,最大遍历深度为表数量+1
  2. 如果表数量大于7,那么,最大遍历深度为7

发现没,MySQL将7作为动态计算最大遍历深度的阈值,你可以想想为什么用7?但是,从这个动态计算得到的阈值7来看,MySQL可能还是建议我们联表遍历的深度不要超过7。PS:当然最合理的方式是动态统计遍历深度性能,然后,根据统计结果确定最大遍历深度,MySQL源码里做了这样的TODO,这是给我发挥的机会吗,哈哈哈!开玩笑的。

因此,这就回答了我文章标题的问题:Join查询联表的数量最大不要超过多少?答案是7。因为如果我们联表的数量小于等于7,那么,势必从一张表开始遍历其他表的深度不会超过7。

既然可以将最大遍历深度的阈值调整为0,那么,我们该如何调整呢?具体调整方法如下:

set optimizer_search_depth = 0;

总结

最后,我们来总结一下今天的内容:联表成本分析的核心数据结构Join以及驱动表选择的过程。
同时,我还提供了2个参数调优:

场景参数调优
如果表连接数不多建议set optimizer_prune_level = 0; 关闭剪枝功能
如果表连接数小于等于7议set optimizer_search_depth = 0; 让MySQL自身动态计算最大遍历深度

还回答了标题的问题:Join查询联表的数量最大到底不要超过多少?
MySQL给到的建议是:Join查询联表的数量最大不要超过7。

当然,如果你对本文的内容还有疑惑,也欢迎在评论区提问,知无不言,言无不尽!

标签:有人,Join,查询,relation,user,联表,MySQL,JOIN,成本
来源: https://blog.csdn.net/Monsterof/article/details/120534283