对Hash Join的一次优化

eagle_fan

原帖由 rollingpig 于 2008-3-20 08:42 发表
正好相反，我说的是buffer_gets低，而CPU Time高（相对来说）

是我看错你前面的意思了

yxyxxy

原帖由 eagle_fan 于 2008-3-19 23:56 发表
其实想到问题可能出在hash key的时候已经基本解决了，hash join trace因为常常用，所以很自然就想到了 （建议大家熟练掌握，还有10032,10033 sort trace）

在实际调优中，index scan有问题的很多（index scan的access,filter估计大家都会注意到的[/PHP]

  能否举出几个例子？

xjyxhm

感觉这样的逻辑，SQL语句就不应该用DISTINCT写，而应该用EXISTS来做

anlinew

原帖由 xjyxhm 于 2008-3-20 14:56 发表
感觉这样的逻辑，SQL语句就不应该用DISTINCT写，而应该用EXISTS来做

xjyxhm

还有一点就是，HASH连接过程中有动态角色互换，因此不应该用LEADING来指定那个表为驱动表哪个表为被探测表吧

lhlzjx

经典！

jiangjh62

真不错啊好好学习一下

foreverlee

挺好的帖子

提问:

第一步建立Hash buckets时 Oracle是怎么把build_table的值影射到Hash buckets里的,每一个hash bucket里会有多少值?
难道像楼住这样得出来的么？
select count(*),col_name from build_table
group by col_name

谢谢

sharklove

通常情况下，我都是同时关注执行计划和统计信息，因为执行计划中的cost和card值貌似不太可靠（尤其是统计信息很旧了），所以统计信息是一个很好的参考。不过consistent read不能反映hash join的执行情况，像LZ这种问题，我就没有办法了，不过10104倒是一个不错的办法，之前都没有用过，以后再遇到这种问题，就多了一个办法了。

eagle_fan

原帖由 foreverlee 于 2008-3-21 00:34 发表
挺好的帖子

提问:

第一步建立Hash buckets时 Oracle是怎么把build_table的值影射到Hash buckets里的,每一个hash bucket里会有多少值?
难道像楼住这样得出来的么？
select count(*),col_name from build_table
group by col_name

谢谢

oracle通过hash函数生成值hash(col_name) ，然后根据hash(col_name)投放相应的bucket

所以col_name值相同肯定会在同一个bucket里面，col_name值不同也可能出现在一个bucket里面，因为当col_name number of distinct value > number of buckets是，难免会出现一个篮子里面有多个鸡蛋的情况