oracle表语句u，多表使⽤u_hashhint，你写对了吗？oracle的online document⾥⾯，对u_hash的hint语法是这样描述的：
/*+ USE_HASH ( [ @ queryblock ] tablespec [ tablespec ]... ) */
⽽⼤部分的开发⼈员也确实是这样写的: u_hash(a b) ，这个确实没问题。
当关联的表超过2个的时候，写成u_hash(a b c d)有没有问题呢？
我们先来看⼀个test ca，这个案例根据客户真实案例改编，模拟的是在表关联条件复杂的情况下，优化器对表关联后的结果集估值过⼩，可能使⽤错误的执⾏计划，希望通过增加u_hash hint来优化SQL。
--创建4个表
create table tv as lect rownum as id,a.* from dba_objects a;
create table tt as lect * from tv;
create table tw as lect * from tv;
create table tu as lect * from tv;
--收集统计信息
exec dbms_stats.gather_table_stats(ur,'tw');
exec dbms_stats.gather_table_stats(ur,'tt');公布英文
exec dbms_stats.gather_table_stats(ur,'tu');
exec dbms_stats.gather_table_stats(ur,'tv');
SQL：
permittinglect /*+ u_hash(v t u w) */
count(*) from tv v,tu u,tw w,tt t
where
菲尔普斯里约奥运会
t.id=v.id and t.object_name=upper(v.object_name) and
回馈英文
doubts
w.id=u.id and
t.object_id=w.object_id ated;
真实案例的情况是：SQL正常执⾏时间3.4分钟，某天TV表delete⼀些记录后，执⾏了将近20分钟还没有完成，⽽其中最重要的变化就是执⾏计划其中的⼀个hash join变成了nested loops，虽然hint中已经指定全部表要u_hash。
这个模拟的SQL展⽰的就是真实案例出现异常的情况。其中⼀个步骤使⽤了nested loops，⼤概要执⾏4分钟左右才能完(测试时可以cancel)，全部hash的执⾏计划不到1秒。
当前hint⽣成的执⾏计划：
这个执⾏计划出现了nested loops的情况，没有按照hint的指⽰全部使⽤hash_join，说明这种hint的写法确实是有问题的。那么，正确的写法是怎样的呢？
问题的关键在于：
多表的u_hash，⼀定要配合leading的hint使⽤。
drugs
根据sql的关联条件，我们增加leading的hint再测试⼀下：
freebalect /*+ leading(v t w u) u_hash(u v t w) */
count(*) from tv v,tu u,tw w,tt t
where
t.id=v.id and t.object_name=upper(v.object_name) and
w.id=u.id and
t.object_id=w.object_id ated;
这次，SQL只需要不到1秒时间就能跑出结果了，执⾏计划也正是我们需要的全部hash join：
老友记第六季迅雷下载
在优化器内部⽣成的标准执⾏计划outline data中，上⾯的hint最终被转化成这样：
(有没有注意到，其中leading的第⼀个表没有做u_hash(V)？
这是因为，有第⼆个表的u_hash(t)的存在，t表做u_hash(t)，跟谁做？当然是和第⼀个表V)。
结论：
我们在写多表u_hash(u_nl也⼀样)hint的时候，u_hash的括号⾥⾯是可以放多个表(顺序⽆关)，但是⼀定要结合leading 的hint，才能保证优化器不使⽤其他的join⽅式。 leading⾥⾯表的顺序⾮常关键哦，搞错了会带你去见笛卡尔(cartesian join)。
分享持续更新中，敬请关注：⽼虎刘谈SQL优化
脚本分享在QQ群：16778072
big star欢迎转发分享给更多的朋友
为了⽅便交流，有兴趣的朋友可以加⼊同名微信群：
