为什么不走hash join？

今天，某省的同事来告诉我，表重组后，他用于统计的一个sql脚本运行变慢了，之前只需要17、8分钟能出来的结果，现在1小时40分钟左右才能出来结果。

我们一起来看看脚本中的一个sql：

我们看到这个sql是通过索引后在走nested loops，我们做一个sqltrace来观察一下它的执行时间和consistent gets：

我们看到有270多万个consistent gets，并且这个sql也确实要36分钟才能运行出来，那为什么同事说之前10多分钟就能跑出来？我们来试试hash连接：

呀，走hash连接的话，只要4分多钟就能跑出来，且consistent gets也仅仅只有40万，物理读也小了不少。看来oracle确实没有选择合适的执行计划了。
可oracle为什么没有选择合适的执行计划？难道是统计信息的问题？

难道是tab_2的统计信息太久了导致执行计划出错？尝试备份统计信息并重新分析tab_2之后，再次查看执行计划 ：

天，竟然还是走nl！！

难道是因为servid中的倾斜度的问题？再次查了一下tab_1表中servid=’025001003681′

可以看到其他值的返回数据量确实很小，在返回数据量小的情况下，我们走索引确实是一种高效的查询方式，但是当返回数据很多时，由于nl的比较要花大量的时间，因此时间也就基本消耗在这里了。

对于某一列中的不同数值有不同的倾斜度（skew），要选择不同的执行计划，我们需要在收集直方图：

此时，我们再次检查其执行计划的时候，看到已经走了hash连接了：

这个时候，我们不加hints，oracle已经正确的选择了执行计划。至此，不走hash join是因为索引列的倾斜度的问题，收集直方图后，问题搞定。