温馨提示:文本由机器自动转译,部分词句存在误差,以视频为准
00:00
那像其他的r Bo规则,一个叫列裁剪,一个常量替换。其实从刚才过滤条,呃,执行计划咱们是可以看到,所谓的列裁剪,就是扫描数据源的时候,只读取那些与列查询字相关的字段。还有一个常量替换这些我们直接看刚才执行计划瞅一眼就行,比如说随便挑一个啊,呃,这个应该是这个吧。这个语句。咱们来瞅一瞅啊,就这个语句两张表进行阻碍关联过滤,条件在V啊,那我们来分析一下这个执行计划,首先是对右表的读取的时候,这project不就是列裁剪吗?对吧?你看看咱们对于右表哪些字段要保留,首先关联的几个字段肯定都要吧。那你看dt dn cos ID那又多了一个cos,内join的时候没体现,但是咱们在最外层的select用到了。
01:04
这个cos内,所以它在这也会保留它,那么其他额外的字段它就不要了,对吧,他就不要了,这就是一个列裁剪,另外一个呢,咱们看看左表的列裁剪。看看这儿。看所表的最终结果就行啊,那么这一块呢,你看同样的关联条件iddt dn它都要保留,那同样咱们在最外层that加了一个。Cos内,所以呢,它也保留了一个cos内。啊,这个就比较直观了啊,那还有一个咱们所谓的糖量替换是啥意思,也就在这个地方,咱们过滤条件是二加三,它的结果是不是固定是五啊。如果他不用常量替换,会有啥性能问题呢?它就是每条数据再去比较的时候。
02:01
比如说123456这么多条数据去比较。那比如说先扫出这一行,他才要现场对二加三计算出一个结果之后跟一做一个比较,然后扫描二这一条的时候,它同样的要先计算出二加三等于五,然后再去跟二比较,也就是说你每一条数据去过滤比较的时候,都得去执行一次计算,那这样可想而知性能非常低下,所以他会干嘛呢?他会首首先将这种结果为一个糖量不会变的,先计算出一个结果,替换掉二加三这个等式,呃,这个计算。那这样的话,每条数据直接跟你一个常量值比较就可以了啊,不需要在现场计算,虽然看起来很简单,但确实呃能够帮我们节省很多呃性能上的损耗啊,那我们来看看执行计划这里,其实我们从位置下推这里大家就能看到它这个时候下推比较的都是谁呀,五了,不再是二加三了,对吧?
03:06
这就所谓的替换啊,这就比较简单直观了啊,我们这个就是啊,稍微搂一眼啊就OK了。
我来说两句