性能优化 你是否忽视了这一点
作者: zhaolinjnu, 出处:blog, 责任编辑: 李书琴,
2008-04-07 00:21
在OLTP的应用环境下，我们对一个数据库系统进行优化，通常来讲，可以从两方面着手。第一个方面，优化应用实现逻辑;第二个方面，优化数据库中的SQL语句。优化数据库中的SQL语句，可能大家通常会想到，为SQL创建合适的索引，让SQL走正确的执行计划。
在OLTP的应用环境下，我们对一个数据库系统进行优化，通常来讲，可以从两方面着手。第一个方面，优化应用实现逻辑;第二个方面，优化数据库中的SQL语句。优化数据库中的SQL语句，可能大家通常会想到，为SQL创建合适的索引，让SQL走正确的执行计划。但最近优化了好几个这样的案例，情况却不是这样的。另外一点，我们要学会利用statpack这个工具，这可是个发现有性能问题的SQL的利器。
优化前，在statpack中发现有一条语句,此语句物理读排名第二,逻辑读也消耗不少：
逻辑读如下：
| CPU Elapsd Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value --------------- ------------ -------------- ------ -------- --------- ------ 13,575,220 464,573 29.2 13.8 798.17 9601.89 379611895 Module: java@favorite66.cm2 (TNS V1-V3) select collect_info_id as id, user_id as userid, USER_NICK as userNick, collect_item_id as collectitemid, isshared, note, status, collect_time as collecttime,tag as tag from collect_i nfo where status > -1 and collect_item_id = :1 and user_i d = :2 |
物理读如下:
| CPU Elapsd Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value --------------- ------------ -------------- ------ -------- --------- -------- 987,848 464,573 2.1 8.8 798.17 9601.89 379611895 Module: java@favorite66.cm2 (TNS V1-V3) select collect_info_id as id, user_id as userid, USER_NICK as userNick, collect_item_id as collectitemid, isshared, note, status, collect_time as collecttime,tag as tag from collect_i nfo where status > -1 and collect_item_id = :1 and user_i d = :2 |
上面这条语句的执行计划如下：
| ---------------------------------------------------------------------------- | Operation | PHV/Object Name | Rows | Bytes| Cost | ---------------------------------------------------------------------------- |SELECT STATEMENT |----- 379611895 -----| | | 2 | |TABLE ACCESS BY INDEX ROWID |COLLECT_INFO | 1 | 61 | 2 | | INDEX RANGE SCAN |IDX_COLLECT_INFO_ITE | 1 | | 4 | ---------------------------------------------------------------------------- |
- 本文关键词：
