本文共 3153 字，大约阅读时间需要 10 分钟。
今天碰到一个开发人员反映SQL执行时间过长。根本无法得到结果集。
看到服务器压力也没有很高，估计又是一个非常消耗磁盘的查询。果然，发现是一个200w的表和一个超过1100w表的HASH JOIN .
简单的帮助优化了一个SQL后，SQL如下:
select count(ui.usin_uid_fk)
from table1 av, table2 ui
where av.av_usse_activatedate >= to_date('20090102', 'yyyymmdd')
and av.av_usse_activatedate < to_date('20090401', 'yyyymmdd')
and av.av_usse_uid_fk = ui.usin_uid_fk
and ui.usin_mcnc_fk =XXX%'
不难想象执行的不是很理想。近20分钟的执行时间，真是让人崩溃。
COUNT(UI.USIN_UID_FK)
---------------------
1918591
Elapsed: 00:19:03.07
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
32921639 consistent gets 352073 physical reads
0 redo size
395 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
对于那张TABLE2的大表（符合条件的超过1100w），决定试图通过并行来提高执行速度。SQL如下：
select /*
+parallel (tbl_userinfo 4)*/ count(ui.usin_uid_fk)
from table1 av, table2 ui
where av.av_usse_activatedate >= to_date('20090101', 'yyyymmdd')
and av.av_usse_activatedate < to_date('20090401', 'yyyymmdd')
and av.av_usse_uid_fk = ui.usin_uid_fk
and ui.usin_mcnc_fk like 'XXX%';
执行效果还是非常明显的。从19分钟多到1分45秒！其中consistent gets更是减少了一个数量级 -:)
COUNT(UI.USIN_UID_FK)
---------------------
1918591
Elapsed: 00:01:45.15
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2571 109 consistent gets 124523 physical reads
0 redo size
395 bytes sent via SQL*Net to client
504 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
因为这个服务器为2×4核心的cpu，应该可以算是8个CPU，所以应该可以通过增加并行度来进一步减少执行时间。如下SQL：
SQL> select /
*+parallel (tbl_userinfo 8)*/ count(ui.usin_uid_fk)
2 from table1 av, table2 ui
3 where av.av_usse_activatedate >= to_date('20090101', 'yyyymmdd')
4 and av.av_usse_activatedate < to_date('20090401', 'yyyymmdd')
5 and av.av_usse_uid_fk = ui.usin_uid_fk
6 and ui.usin_mcnc_fk like '460%';
COUNT(UI.USIN_UID_FK)
---------------------
1949033
Elapsed: 00:00:20.60 Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2607524 consistent gets
55050 physical reads
0 redo size
395 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
可以说还是比较理想的。只有20S左右了。虽然最大并行度可以到CPU*2，但是效果未必会好。进一步做一个16个并行度的SQL执行测试。
COUNT(UI.USIN_UID_FK)
---------------------
1949033
Elapsed:
00:00:20.64 Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2607524 consistent gets 55299 physical reads
0 redo size
395 bytes sent via SQL*Net to client
504 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
没有任何提高，并且执行时间还稍高于并行度为8的SQL。
通过以上测试我们不难发现：
在处理大量数据查询，例如出现HASH JOIN的情况下，并行查询非常有效果的。也就是说并行查询在数据仓库这样的应用中会“大显身手”。
但是并行查询的使用还是有很多限制的。例如相对较小的数据查询和连接是会适得其反的。盲目增加并行度也是大忌，相对来讲，并行度和CPU数相同比较好。这里的CPU数应该是指的核心数。例如服务器中有一个CPU是4核心的，并行度为4是好的。
技术很难有十全十美的，最重要的是对于特定技术的使用要恰到好处，保证扬长避短。 -:)
----------------------------
以上测试环境：
ORACLE 9.2.0.4
RHEL 4 U4
转载地址：http://djnsi.baihongyu.com/