00:00
Order。那这个是应该是不管是什么op引擎都会提供的一个优化功能,说白了就是自动调整九引的顺序啊,比如说我有很多张表abcd啊,四张表要做九引,按照我的语法是A跟B,先九引,再跟C9引,再跟D9引,对吧,那么这样就比较。能实现,但是效率不一定高,那如果D表示数据量比较小,那我能不能先用A表跟D表进行交易,那这样产生的中间结果是不是就变少了,那整体效率就能提高了。好,那我们知道在circle。里边通常呢,我们呃,解析的时候是不是有一个叫逻辑执行计划的优化,还有一个物理执行计划的优化,对吧?那如果是逻辑计划一般是基于r Bo r Bo就是类呃基于规则的一些优化,像什么位置下推这种规则,那还有一个物理执行计划阶段做的一个优化叫CPU。
01:09
CBO啊,就是基于代价的一个优化,那这个joiner一般就是在CVO里面去实现。那同样你看啊,通过代价模型就是指的CPU啊,自动调整so中的就是顺序获得最优的,就像那这个参数,我们一般也是建议开启,那呃,我们了解一下它的原理。呃,比如说看下面这张图啊,是三张表要做Q引啊,啊根一是跟二跟三分别代表三张表,那我们正常一个,比如说我们写的可能是1Q引二啊对吧,然后再继续Q引三,按照circle口语法顺序是一跟二,先join再跟3Q引,那我们看啊第一次交引的时候。
02:02
表一一千行,表二一百行,这时候中间结果是多少?比如说是有2000行,这个时候他们交引完的结果,再跟表三才实行数据做一个交易啊,这是一个不优化的逻辑,但是通过自动调整之后,他发现表三数据量这么小,为什么不先把它交引处理完呢?对吧?啊,所以它会自动调整成什么样呢?啊,我表一一千行跟表三这个小表,我先做就业,那得到的中间结果只需要100条。啊,这个这个得到几条不一定,看你的关联条件是不是啊,咱们这边只是一个一个案例说明啊,那中间结果肯定是少了的,那接下来再去扫描表二啊,也就是有100张一百一百条数据的这张表再做一个交,你看中间数据量少了,第一次交引效率提高了,那最终这个整体执行。呃,效率就非常高了,这个就是自动做的事啊。
03:04
那我们了解一下它的底层逻辑啊,它的底层逻辑是怎么优化呢?尽量的让大跟小做一个交易,对吧,优先让小去跟大表做交易。那这样它生成的中间结果是尽可能小,这是它优化的第一个原则。呃,第二一个呢,把有条件的join表放前面,也就是说,比如说我表一表二啊1JOIN2JOIN3对吧?啊,那如果我只的三这张表有加过滤条件。不管是where写还是on写也好,那优先呢?呃,跟他做一个,就因为它有过滤,过滤完的数据量就比较少,数据条数也比较少。尽量让有条件的先啊,先过滤啊。呃,另外一个就哈希交蚓优先级高于另外的这种就蚓这种就是什么呢?像比如说迪卡尔基的那种就对吧啊非等值啊哈希交引,我们前面介绍过,主要是在等值交引的场景啊,要做一个哈希交换啊数据交换。
04:07
嗯,好,那说这么多,我们直接通过一个案例来演示啊,那我们之前建的表有这么一张表,还有一张表二啊,还有一个表三。啊,表三这三张表作为一个交易啊,那关联条件都是什么呢?UID啊。那按照我们的顺序,是不是这个一跟二先揪完再跟三是不是啊。那我们现在先来,呃,我先看一下那个参数吧,So。Variables like什么reorder,对吧?Join的,嗯。看一下这个参数的默认值是一个什么呢?In cost base就默认是不开启,那这个时候呢,我们来执行这个SQL语句,那我们是查看它的一个执行计划,并且我以图的方式来看啊,不然太长了不好看,我们图片呢就特别明显了,对吧?好,我们先来看一眼粘贴,哎,我缩小一点。
05:13
我们看一下第一次灸隐发生在哪,先找第一次就好,这是第一次就这是第二次就蚓对吧?那我们现在要看的是第一次交运是谁跟谁来往檄翻啊。是不是表一啊,好,那看另一边是谁。是表二对吧,也来啊,也就是说这个交引是表一含有表二的交是跟我们搜狗的写的顺序是一样的对吧?呃,然后呢,第二次交易是把中间结果跟表三做一个交易。对吧,你就往这边往下拉,右边往下拉,这个是表三。啊,这个是不帮我们做调整,那接下来我们要做一个事儿啊,我们将这个参数设为处,再来看一下刚才这个舌头。
06:06
好,现在是处了对吧,那我直接上翻,上翻还是这个色口啊,回车来注意看找第一次就。这是第一次。这第二次,那接下来看第一次是谁跟谁还是一个表一啊,再看另一边变成了谁呀,表三。对吧,当我们调整了顺序,这里变成了一就三。那另一边这个肯定是什么。第二次经才join那个表二啊,那往下往下看一点对吧,表二那这个就是reorder啊,那为什么会这么调整,因为我表上是没数据,还记得吧,我前面是不是建了一张空表。啊,这个是一个空表吧,我没记错的话,它数据量比较小,对不对,这是我前面建了一张空表,好,这个就是joyro自动的帮我们调整顺序。
07:04
达到一个最优的效果。那接着呢,我们顺便了解一下join的一个优化原则啊,就怎么样来使用join啊,效率会更好一点啊,第一个原则呢,我们尽量。关联的字段选择同类型的或者简单类型的列同类型呢?当然不同类型也可以做,但是它是不是要自动做一个类型转换,对吧,它会呃自动做一个cast。那做这个事儿肯定是多做了一些事情。另外一个使用简单的列,本身它的效率肯定就高嘛,复杂力量肯定就慢啊,这当然是尽量啊,如果你实际需求没办法,那你就啊也无所谓了,其实呃,第二一个尽量选择T列进行交易,你不要呃,比如说在聚合模型里面啊,你用一个sum类型的列去。Join,这个原因呢,在runtime Fi的时候我们也提到过,对吧,它key列呢,在延迟物化上能提到一个比较好的效果,或者说key列本身是排序列啊,那它效率是本身就高啊。
08:12
呃,其次呢,大表之间的交易,我们尽量用什么?会对对吧,使用呃,这样可以避免一个shuffle。那如果再不行,我们再去考虑用那个bucket的沙join,这个我们前面介绍join的时候都有提到过啊,还是一样的道理。还有一个就我们提到过的RO Fi啊,前面也演示过了,呃,它是目的呢,是为了提高我们的效率啊,去做一个下推是吧,甚至呢,下推到那个存储引擎。那要注意的时候,他也是有一定副作用的,要根据具体情况去使用,就比如说我们用那个布隆。对吧。布隆的方式过滤是不是还有些情况,注意事项我们也提过,还有呢,印用印这种方式,它是不是有个限制,超过1024,默认超过1024,它是不是就失效了?
09:08
啊,等等,这些都是可以去考虑的。第三一个涉及多表join,就我们刚才提到,我们可以开启一个reorder,让它自动帮我们调整。那下面这张图就是官方在分享的时候给到的一个建议啊,一张PPT啊,那也给我们上面讲的,呃,就差不多啊。
我来说两句