3.2.5数据库优化
【案例】某企业内部核心业务系统数据库出现业务高峰CPU使用率居高不下，存在大数据量查询、多表连接造成查询性能下降、表索引建立不合理等问题，最终通过以下办法将业务高峰期CPU使用率控制在30%内：
在SQL*PLUS下执行下面语句：
SQL> set line 1000 --设置每行显示1000个字符
SQL> set autotrace traceonly --显示执行计划和统计信息，但是不显示查询输出
执行效率低下SQL语句：
select variablein0_.TOKENVARIABLEMAP_ as TOKENVAR7_1_
from JBPM_VARIABLEINSTANCE variablein0_
where variablein0_.TOKENVARIABLEMAP_ = '4888804'
查看优化前的执行计划：
执行计划
----------------------------------------------------------
Plan hash value: 3971367966
-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time|
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 12 | 612 | 12408 (2)| 00:02:29 |
|* 1 | TABLE ACCESS FULL| JBPM_VARIABLEINSTANCE | 12 | 612 | 12408 (2)| 00:02:29 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("VARIABLEIN0_"."TOKENVARIABLEMAP_"=4888804)
统计信息
----------------------------------------------------------
1 recursive calls
1 db block gets
48995 consistent gets
48982 physical reads
0 redo size
1531 bytes sent via SQL*Net to client
248 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
9 rows processed
从执行计划看该语句缺少索引导致全表扫描。消耗总一致性读占用为：48995，平均每行一致性读：48995/9=5444，物理读为：48982，不满足正常性能需要。创建索引优化后的执行计划：
统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
6 consistent gets
4 physical reads
0 redo size
1530 bytes sent via SQL*Net to client
248 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
9 rows processed
从执行计划看该语句消耗总一致性读占用为：6，平均每行一致性读：6/9=0.67，物理读为：4，为比较高效的SQL。
一般认为平均每行一致性读超过100的为执行效率比较低的SQL，10以内为执行效率比较高的SQL。 |
