Oracle中捕获问题SQL解决CPU过渡消耗

核心提示： 至此，此问题得以解决.8.性能何以提高?回答这个问题似乎是多余的,我只想重申一点:有效的降低SQL的逻辑读是SQL优化的基本原则之一，Oracle中捕获问题SQL解决CPU过渡消耗(8)，我们来比较一下前后两种执行方式的读取及性能差异，全表扫描的性能：SQL> select i.vc

至此，此问题得以解决.

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(也许就是你)就是最后的一环,你必须能够快速的诊断并解决各种复杂问题。