看看這同一句sql,scan index佔用的資源大了很多!!
users: 1815331行 index: inx_mobilephone inx_status pk_username
spool: 1073行 pk_username
SQL>
SQL> select spool.username, spool.sender, spool.message, spool.sid,
users.mobilephone from spool, users
where spool.username = users.username and users.status = '0'
and spool.sender!='pica' and
and users.mobilephone is not null and rownum <= 30; 2 3 4 5
no rows selected
Elapsed: 00:00:01.21
Execution Plan
----------------------------------------------------------
Plan hash value: 119197225
--------------------------------------------------------------------------------
-------------------
| Id | Operation | Name | Rows | Bytes | Cost
(%CPU)| Time |
--------------------------------------------------------------------------------
-------------------
| 0 | SELECT STATEMENT | | 30 | 66390 | 6
1 (22)| 00:00:01 |
|* 1 | COUNT STOPKEY | | | |
| |
|* 2 | HASH JOIN | | 564 | 1218K| 6
1 (22)| 00:00:01 |
|* 3 | TABLE ACCESS FULL | SPOOL | 564 | 1188K| 3
2 (0)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| USERS | 334K| 9148K| 1
6 (0)| 00:00:01 |
|* 5 | INDEX FULL SCAN | INDEX_MOBILEPHONE | 1967K| |
1 (0)| 00:00:01 |
--------------------------------------------------------------------------------
-------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<=30)
2 - access("SPOOL"."USERNAME"="USERS"."USERNAME")
3 - filter("SPOOL"."SENDER"<>'pica' AND "SPOOL"."SENDER"<>'@pica')
4 - filter("USERS"."STATUS"='0')
5 - filter("USERS"."MOBILEPHONE" IS NOT NULL)
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
252154 consistent gets
0 physical reads
0 redo size
292 bytes sent via SQL*Net to client
235 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
發現 consistent gets : 252154 ,比較大,其中用了全表索引掃描,應該是這個導致了consistent gets很高
我下面加了hint,不用全索引掃描,效能得到大的提高!
SQL> select /*+ no_index(users,INDEX_MOBILEPHONE,INX_STATUS) */ spool.username, spool.sender, spool.message, spool.sid,
users.mobilephone from spool, users
where spool.username = users.username and users.status = '0'
and spool.sender!='pica' and
and users.mobilephone is not null and rownum <= 30;
2 3 4 5
no rows selected
Elapsed: 00:00:00.09
SQL>
SQL> set autotrace traceonly
SQL>
SQL> /
no rows selected
Elapsed: 00:00:00.04
Execution Plan
----------------------------------------------------------
Plan hash value: 2723135770
--------------------------------------------------------------------------------
-------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU
)| Time |
--------------------------------------------------------------------------------
-------------
| 0 | SELECT STATEMENT | | 30 | 65550 | 202 (1
)| 00:00:03 |
|* 1 | COUNT STOPKEY | | | |
| |
| 2 | NESTED LOOPS | | 564 | 1203K| 202 (1
)| 00:00:03 |
|* 3 | TABLE ACCESS FULL | SPOOL | 564 | 1188K| 4 (0
)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| USERS | 1 | 28 | 1 (0
)| 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_USERS_UN | 1 | | 1 (0
)| 00:00:01 |
--------------------------------------------------------------------------------
-------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter(ROWNUM<=30)
3 - filter("SPOOL"."SENDER"<>'pica' AND "SPOOL"."SENDER"<>'@pica')
4 - filter("USERS"."MOBILEPHONE" IS NOT NULL AND "USERS"."STATUS"='0')
5 - access("SPOOL"."USERNAME"="USERS"."USERNAME")
Note
-----
- dynamic sampling used for this statement
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
2053 consistent gets
0 physical reads
0 redo size
285 bytes sent via SQL*Net to client
235 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7916042/viewspace-1002057/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Oracle 檢視佔用undo大的sql語句OracleSQL
- 查詢UNIX/LINUX 下的佔用CPU資源的SQL語句LinuxSQL
- 收集full table / index scan sqlIndexSQL
- INDEX UNIQUE SCAN,INDEX FULL SCAN和INDEX FAST FULL SCANIndexAST
- OEM模組審計查詢語句佔用較大資源
- index range scan,index fast full scan,index skip scan發生的條件IndexAST
- Index的掃描方式:index full scan/index fast full scanIndexAST
- 高效的SQL(Index unique scan最優化)SQLIndex優化
- 高效的SQL(index range scan優化排序)SQLIndex優化排序
- 高效的SQL(index skip scan使用條件)SQLIndex
- rowid,index,INDEX FULL SCAN,INDEX FAST FULL SCAN|IndexAST
- Index Full Scan vs Index Fast Full ScanIndexAST
- Index Full Scan 與 Index Fast Full ScanIndexAST
- INDEX FULL SCAN和INDEX FAST FULL SCAN的區別IndexAST
- 查詢某佔用資源較多的SQLSQL
- index full scan 和 index fast full scan (IFS,FFS)的不同IndexAST
- INDEX SKIP SCAN適用場景Index
- sql語句引起的CPU佔用國高SQL
- 【INDEX_SS】使用HINT使SQL用索引跳躍掃描(Index Skip Scan)方式快速獲取資料IndexSQL索引
- INDEX FULL SCAN和INDEX FAST FULL SCAN區別IndexAST
- index full scan 和 index FAST full scan 區別IndexAST
- Index Full Scan 與 Index Fast Full Scan (Final)IndexAST
- INDEX SKIP SCANIndex
- Clustered Index Scan and Clustered Index SeekIndex
- 快速清除佔用資源大的會話(from eygle)會話
- 理解index skip scanIndex
- Index Unique Scan (213)Index
- 【TUNE_ORACLE】列出走了INDEX FULL SCAN的SQL參考OracleIndexSQL
- 【TUNE_ORACLE】列出走了INDEX SKIP SCAN的SQL參考OracleIndexSQL
- index為什麼可能會比table大很多Index
- PostgreSQL DBA(119) - pgAdmin(LIMIT:Index Scan vs Bitmap Index Scan)SQLMITIndex
- Index Full Scan和Index Fast Full Scan行為差異分析(上)IndexAST
- Index Full Scan和Index Fast Full Scan行為差異分析(下)IndexAST
- 查詢最佔資源、CPU、記憶體、和執行最長的SQL語句記憶體SQL
- mysql loose index scan的實現MySqlIndex
- [轉貼]Skip Scan IndexIndex
- 關於INDEX SKIP SCANIndex
- Index Range Scan (214)Index