關(guān)于索引是什么的最簡單的比喻是，索引之于表數(shù)據(jù)如同目錄之于一本書。
通過目錄的頁碼我們可以快速的定位一個內(nèi)容，同樣通過索引記錄的rowid我們可以快速的定位一條數(shù)據(jù)。
如同目錄很難針對書中每個字詞一樣，索引也很難針對所有字段。
我們通常索引最能代表章節(jié)，記錄屬性的內(nèi)容。
索引并非總能帶來性能提升，但是通常情況下，索引能加快訪問，所以建表的時候，你一定要知道還有索引這樣一類對象。
下面這個案例是我們絕對不應該和不想看到的。
今天一個部門報數(shù)據(jù)庫巨慢無比，上去看了一下，抓到如下的SQL:
SQL> select sql_text
2 from v$sqltext a
3 where a.hash_value = (
4 select sql_hash_value from v$session b
5 where b.sid='&sid'
6 )
7 order by piece asc
8 /
SQL_TEXT
----------------------------------------------------------------
select * from i_cm_power t WHERE T.SJH='13911xxxxx6'
檢查了一下該查詢訪問的數(shù)據(jù)表,居然一個索引都沒有:
SQL> select index_name from dba_indexes where table_name=upper('i_cm_power');
INDEX_NAME
------------------------------
沒有索引意味著，即使為了獲取這一條記錄，Oracle也必須對5.28G的一個表進行全表掃描，如果不慢那就怪了:
SQL> col segment_name for a20
SQL> select segment_name,bytes/1024/1024/1024
from dba_segments where segment_name=upper('i_cm_power');
SEGMENT_NAME BYTES/1024/1024/1024
-------------------- --------------------
I_CM_POWER 5.28173828125
創(chuàng)建一個索引再說:
SQL> create index idx_i_cm_power_sjh on i_cm_power(sjh);
Index created.
Elapsed: 00:20:50.73
SQL> col segment_name for a20
SQL> select segment_name,bytes/1024/1024 MB
2 from dba_segments where segment_name=upper('idx_i_cm_power_sjh');
SEGMENT_NAME MB
-------------------- ----------
IDX_I_CM_POWER_SJH 1360
SQL>
無疑這個索引對于這樣的簡單查詢是大有益處的:
SQL> select * from i_cm_power t WHERE T.SJH='13911xxxxx6';
Elapsed: 00:00:00.07
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'I_CM_POWER'
2 1 INDEX (RANGE SCAN) OF 'IDX_I_CM_POWER_SJH' (NON-UNIQUE)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
6 consistent gets
0 physical reads
0 redo size
1022 bytes sent via SQL*Net to client
503 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
2 rows processed
然而在實際中，你需要考慮更多的因素。
增加索引會占用更多的存儲空間；索引的維護會增加數(shù)據(jù)庫的負擔，如果有海量的數(shù)據(jù)加載，可能會極大影響性能...
所以事實可能總是比你想象的更復雜，你只有知道的更多...