Oracle中捕获问题SQL解决CPU过渡消耗(1)(5)

时间:2011-04-12 23:18来源:未知作者:admin 点击: 次

分享到：

8.性能何以提高? 回答这个问题似乎是多余的,我只想重申一点: 有效的降低SQL的逻辑读是SQL优化的基本原则之一，我们来比较一下前后两种执行方式的读取

8.性能何以提高?

回答这个问题似乎是多余的,我只想重申一点:

有效的降低SQL的逻辑读是SQL优化的基本原则之一，我们来比较一下前后两种执行方式的读取及性能差异。

全表扫描的性能：

SQL> select i.vc2title,i.numinfoguid 
2 from hs_info i where i.intenabledflag = 1 

3 and i.intpublishstate = 1 and i.datpublishdate <=sysdate 
4 and i.numcatalogguid = 3475 
5 order by i.datpublishdate desc, i.numorder desc ; 
352 rows selected. 
Execution Plan 
---------------------------------------------------------- 
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=541 Card=1 Bytes=106) 
1 0 SORT (ORDER BY) (Cost=541 Card=1 Bytes=106) 
2 1 TABLE ACCESS (FULL) OF ’HS_INFO’ (Cost=531 Card=1 Bytes=106) 
Statistics 
---------------------------------------------------------- 
0 recursive calls 
25 db block gets 
3499 consistent gets 
258 physical reads 
0 redo size 
14279 bytes sent via SQL*Net to client 
2222 bytes received via SQL*Net from client 
25 SQL*Net roundtrips to/from client 
2 sorts (memory) 
0 sorts (disk) 
352 rows processed

使用索引的性能：

SQL> select i.vc2title,i.numinfoguid 
2 from hs_info i where i.intenabledflag = 1 
3 and i.intpublishstate = 1 and i.datpublishdate <=sysdate 
4 and i.numcatalogguid = 3475 
5 order by i.datpublishdate desc, i.numorder desc; 
352 rows selected. 
Execution Plan 
---------------------------------------------------------- 
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=12 Card=1 Bytes=106) 
1 0 SORT (ORDER BY) (Cost=12 Card=1 Bytes=106) 
2 1 TABLE ACCESS (BY INDEX ROWID) OF ’HS_INFO’ (Cost=2 Card=1 
Bytes=106) 
3 2 INDEX (RANGE SCAN) OF ’HS_INFO_NUMCATALOGGUID’ 
(NON-UNIQUE) (Cost=1 Card=1) 

Statistics 
---------------------------------------------------------- 
0 recursive calls 
0 db block gets 
89 consistent gets 
0 physical reads 
0 redo size 
14279 bytes sent via SQL*Net to client 
2222 bytes received via SQL*Net from client 
25 SQL*Net roundtrips to/from client 
1 sorts (memory) 
0 sorts (disk) 
352 rows processed

consistent gets从3499 到89,我们看到性能得到了巨大的提高。

结束语

通常,开发人员很少注意SQL代码的效率,他们更着眼于功能的实现. 至于性能问题通常被认为是次要的,而且在应用系统开发初期,由于数据库数据量较少,对于查询SQL语句等,不容易体会出各种SQL句法的性能差异.

但是一旦这些应用作为生产系统上线运行,随着数据库中数据量的增加,大量并发访问,系统的响应速度可能就会成为系统需要解决的最主要的问题之一.

在少量用户下性能可以接受的SQL,可能在大量用户并发的条件下就会成为性能瓶颈。在我这个案例中,开发人员很难相信仅只一条SQL语句就导致了整个数据库的性能下降。

然而事实就是如此,一条低效的SQL语句就可能毁掉你的数据库,所以在系统设计及开发过程中,你必须考虑到诸多细节,严格的测试也是提早发现问题的有效方法。

如果不幸以上环节都被忽略,那么,DBA(也许就是你)就是最后的一环,你必须能够快速的诊断并解决各种复杂问题。

(责任编辑：铭铭 mingming_ky@126.com TEL：（010）68476636)