从一条SQL看基于ORACLE的SQL优化_PART4

接PART3：

2.6 逻辑重写让SQL起飞

2.6.1逻辑改写-构造高效HASH JOIN代替低效FILTER

 回到原来的中，看如何改写，通过分析，可以改为JOIN形式：

1）改写后执行时间从2小时到8分钟，返回360w行+。虽然执行计划更复杂了，但是充分利用了HASH JOIN,MERGE JOIN这种大数据量处理算法代替原来的FILTER，更高效。如果不走OR扩展走什么？（走NESTED LOOPS，对IMS_NUM_INFO扫描从4次到1次，也很慢）

2）OR扩展存在缺点，大表还是多次被访问，还能继续优化吗？

2.6.2彻底重写-消除OR扩展的HASH JOIN重写思路

  上一次重写，等于使用了第一种方法，用UNION/UNION ALL消除FILTER，那么如何消除UNION/UNION ALL呢，也就是要将OR语句合并为AND！

追本溯源，从SQL含义出发，上面含义是ERR表的TMISID截取前8,9,10,11位与TMI_NO_INFOS.BILLID_HEAD匹配，对应匹配BILLID_HEAD长度正好为8,9,10,11。很显然，语义上可以这样改写：

  ERR表与TMI_NO_INFOS表关联，ERR.TMISID前8位与ITMI_NO_INFOS.BILLID_HEAD长度在8-11之间的前8位完全匹配，在此前提下，TMISID like  BILLID_HEAD||’%’。

 

  现在就动手彻底改变多个OR子查询，让SQL更加精简，效率更高。

2.6.3彻底重写-消除OR扩展的HASH JOIN让SQL起飞

通过上一节的思路，改写SQL如下：

执行计划如下：

  现在的执行计划终于变的更短，更易读，通过逻辑改写走了HASH JOIN，那速度，杠杠的，最终一条返回300多万行数据的SQL原先需要12小时运行的SQL，现在3分钟就执行完了。
  思考：结构良好，语义清晰的SQL编写，有助于优化器选择更合理的执行计划，看来编写SQL真的有很多值得注意的地方。

未完待续，见PART5：