通过分析SQL语句的执行计划优化SQL(总结)

wjw0577 · 发表于 2006-1-14 00:04

大家说好就是真的好！！！哈。。。。

UC- · 发表于 2006-1-14 05:49

Excellent!

Thanks,

lwlava · 发表于 2006-1-14 08:44

顶一下，不错！分析的比较透彻。

m77m78 · 发表于 2006-1-14 10:51

很久没有见到这样好的文章了，为你鼓掌！
非常感谢你的奉献。

SunnyXu · 发表于 2006-1-17 12:30

[\CODE]
这样的SQL G该如何优化：
update table1 a set col1='aaa'
where exists (select 1 from tab2 b where a.col2=b.col3 and b.col4 in ('a','b','c','d','e');
table1 记录为1800万，table2为3万多。col2列无索引,单独用col4选取b表5000条记录，加上a表200多万，cbo选择为hash，觉得有点慢啊
[/CODE]

对于update语句的优化，可以分为2步：
1.优化select col1 where exists (select 1 from tab2 b where a.col2=b.col3 and b.col4 in ('a','b','c','d','e');
如果该语句运行的很快，则可以转为第二步
2. 对update部分的优化
可以看：
http://blog.csdn.net/lunar2000/archive/2005/06/27/404090.aspx

玉面飞龙 · 发表于 2006-1-17 13:23

最初由 SunnyXu 发布
[B][B]具体案例分析：[/B]

[B]环境：oracle 817 + linux + 阵列柜[/B]
      0  recursive calls
   8823  db block gets
56650250  consistent gets
1413250  physical reads
      0  redo size
      316  bytes sent via SQL*Net to client
      421  bytes received via SQL*Net from client
      2  SQL*Net roundtrips to/from client
      2  sorts (memory)
      0  sorts (disk)
      1  rows processed
注意上面2个执行计划对应的statistics部分好像有问题，我正在重测，但因系统出现问题，需要过些日子才能测试完。
。 [/B]

可以尝试full table scan+ parallel+ hash join 可能更快。小表应该完全可以放到hash_join_area_size中

SunnyXu · 发表于 2006-1-17 13:56

这个我可以也测一下。

hexianguo · 发表于 2006-1-17 14:05

好文，
3Q

fire_in_mind · 发表于 2006-1-17 15:11

真是难得的好文，佩服楼主！！！！！！！！！

[精华] 通过分析SQL语句的执行计划优化SQL(总结)

顶，支持！