好久没更新了，也不知道天天忙个啥锤子了！！！
前段时间夜间有一个sql，晚上将数据库部分节点磁盘占满了，导致夜间部分调度失败了。早起我去查看日志定位问题，发现跑了8个多小时的sql。。。具体sql如下：

INSERT INTO otemp.L_TRUCK_07 
     select P1.*,max(P4.LAST_AMT) LAST_AMT  
       From otemp.L_TRUCK_06 P1 -- 1千万+
        left join TVIEW.T_ITEM P4 -- 50亿+
         on P1.PONO=P4.PONO AND P4.COVCD in (SELECT KIND FROM CT.D_KIND WHERE KNAME='三XX') -- 这个只有4个类型
         where 1=1 
       group by 1,2,3,4,5,6,7,8,9,10,11;

我一看这个sql及表数据量，我就看sql不对，因为取p4表就一个字段，完全可以先把P4的数量先取出相关的然后再关联啊。我就告知对应项目上的人此sql有问题。。。
过会告诉我说此sql没问题，无需优化，就是数据库的问题。解释的原因是p1表数据唯一，不涉及重复，那么关联是可以直接取出p4表的相关数据，并且在关联条件上写了and了（其实后边优化时候我探查了数据，是有多条的，按现有的话就是先数据关联变大然后再分组取最大），他认为没问题。。。而且反馈说之前在另一个数据库上很快就跑出来了，但是在这个上边就不行了。。。差点被他们说的我都怀疑自己错了。还说上个月9个多小时也没事。
那凡事多试一试呗，看看执行计划，按自己思路试一试呗！我让他们在临时表帮我恢复了下表的数据， 告诉他们我自己要优化！！！毕竟8个多小时才能执行完，不行效率低而且影响太大，我本着叔可忍婶不可忍的态度，开始改写！简单看了下执行计划没有重分布操作，就按我刚开始第一段说的，应该把大表数据降低再关联！因为p1表数据唯一，只是取最大值，这样把p4单独计算后都避免了group by了。直接贴sql

INSERT INTO otemp.L_TRUCK_07
       select P1.*,P4.LAST_AMT     
        From otemp.L_TRUCK_06 P1
        left join 
             (select PONO ,max(LAST_AMT) as LAST_AMT from  TVIEW.T_ITEM where  COVCD  in (SELECT KIND FROM CT.D_KIND WHERE KNAME='三XX') group by 1) P4
          on P1.PONO=P4.PONO
        where 1=1;

跑完后直接40秒出结果。。。这对比8个多小时，你们自己想吧！

我还是那就话，凡事多试一试，可能不成，但是不试一定没改变。。。

祝各位身体健康。没事多出去走走，锻炼锻炼。。。