今天有同事告诉我,有个SQL执行了好久好久执行不出来,我说好就是多久?她说一天左右了。真是令人咋舌的SQL。于是我要来了SQL看了看执行计划,确实让人咋舌。
下图中就是执行计划的截图:
25G的COST和75T的Bytes确实是无法承受之重。这个SQL是这样子的:
select部分做了很多sum运算,还有distinct等运算,总之很麻烦,group by部分就是上面的维度。其中最大的表是TABLE3和TABLE4,这两个表所需要查询的数据量都在3G以上,各自差不多3000万数据。
最开始我以为是因为数据量大的原因导致的这个执行计划不可实现,但是在我将TABLE3和TABLE4的相应数据进行压缩后,数据量尽管各自降低到了1G左右,但是执行计划基本上没有改变,这不是我要的效果,于是我注意到了执行计划中红色框中的部分。是不是这里导致了问题的发生?于是我开始检视SQL,就发现了一个问题:TABLE4实际上只有201302的数据,但是为什么这里还需要在左连接的时候写上月份标识,这个比较不合理,而且根据我以往的经验判断,左连接或者右连接的时候,如果and条件写的太多,往往会影响执行计划,导致SQL长久的无法得到结果。于是我做了一个很简单的事情,就是把TABLE4的month_id部分去掉,后来我又进了一步,将TABLE3的month部分也去掉了,这是一个分区表,于是我用了这个办法:
left join TABLE3 partition(part_02),这样即实现了减少and条件的目的,又不会影响数据准确的效果,一举两得。在进行了相关的优化之后,执行计划变成了这个样子:
可以看到执行计划发生了翻天覆地的变化,直接能看到的就是少了NESTED LOOPS OUTER,取而代之的是图中1部分和2部分的HASH JOIN OUTER和TABLE1的HASH JOIN OUTER,这是我喜欢看到的事情,我就喜欢看到简单的执行计划。虽然这个COST依旧很大,但是我实在不想动弹了,这个的数据量实在是太巨大了,我面对的优化工作难度已经无法让我有精力想过去那样,仔细研究思考,然后把COST弄到几千或者更小的程度了,就这样吧,天要下雨,娘要嫁人,随他去吧。
我以前看到论坛上或者书上都在写,如果你的表超过1G,那么最好进行分区,这句话现在我深有体会,如果没有分区表,这个SQL也没有办法优化了(或者说我就没有能力去优化了),因为没有办法去掉month的条件,除非是将特定月份的数据取出来建立一个中间表,不过那么做似乎有点麻烦了,不符合我一贯喜欢写短代码的习惯。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28207565/viewspace-757363/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/28207565/viewspace-757363/