待优化SQL:
SQL执行计划:
(图1)
SQL历史执行情况:
(图2)
作者将SQL的select 部分拿出来测试执行,执行时间0.55秒:
(图3)
根据上面信息, 专家给出了优化方法...执行计划第4步的index full scan明显不正常(正常的Nested Loops应该使用index unique scan), 再结合图3图4执行计划下面显示的 filter("E"."...我的这个优化方法,如果真如图1执行计划显示的那样, 预期优化后的执行时间也就十几毫秒. 但是再仔细想一想,事实应该并非如此....表的统计信息一般是在凌晨收集, 在那个时间段, 业务数据没有代表性,生成的执行计划也是不可信的. 所以这个SQL就不能按照图1执行计划显示的数据去优化....驱动表E返回的结果集大, 虽然我上面的优化方法在驱动表几十万记录的情况下也远比优化前效率高很多, 但是相对来说不如hash join更适合这个SQL,而且用了hash join, 隐式类型转换的问题也就无关紧要了