索引 index
作用:在數據庫中用來加速對錶的查詢
原理:通過使用快速路徑訪問方法快速定位數據,減少了磁盤的I/O
特點:
與表獨立存放，但不能獨立存在，必須屬於某個表
由數據庫自動維護，表被刪除時，該表上的索引自動被刪除。
索引的創建:
自動:當在表上定義一個PRIMARY KEY或者UNIQUE 約束條件時,數據庫自動創建一個對應的索引.
手動:用戶可以創建索引以加速查詢.
當創建索引的時候，Oracle會默認創建一個和當前表相關的索引頁,而索引頁中保存了索引字段和真實的磁盤地址，
當用戶發送sql語句帶了索引的時候，Oracle會到索引頁中查詢索引字段，直接定位磁盤IO，提取數據。
所以索引數據快於全表掃描。
索引的維護
1.建立索引後，查詢的時候需要在where條件中帶索引的字段纔可以使用索引。
2.在經常查詢的字段上面建立索引。不要在所有字段上面建立索引。
3.因爲索引是用來加快查詢速度的，如果一張表經常做insert、delete、update，
而很少做select,不建議建立索引，因爲Oracle需要對索引進行額外的維護
如果一張表字段很少，不建議建立索引。
4.索引是由Oracle自動維護的。索引使用久了會產生索引碎片（磁盤碎片），
影響查詢效果，所以使用久了需要手動進行維護(刪除再重建)。
SELECT * FROM tb_student;
--在tb_student表的name字段上面建立了一個索引
--創建 索引 索引名 on 表 (字段)
create index index_tb_student_name on tb_student (name);
--查詢的時候使用索引(where條件使用建立了索引的字段)
select * from tb_student where name = 'Alice';
--刪除索引
DROP INDEX index_tb_student_name;
/*
sql語句的優化：
多使用共享語句儘量使你的sql語句能夠使用索引。
怎樣使sql語句能夠使用到索引呢：
當sql語句中包含not in,<>,is null,is not null,like '%%'的時候不會用索引。
IN: in會拆成一堆or的,可以使用表的索引。
NOT IN:強列推薦不使用，因爲它不能應用表的索引。
<> 操作符（不等於）:不等於操作符是永遠不會用到索引的，因此對它的處理只會產生全表掃描。
優化方案:用其它相同功能的操作運算代替，如a<>0改爲 a>0 or a<0;a<>’’改爲 a>’’.
IS NULL 或IS NOT NULL操作（判斷字段是否爲空）:
判斷字段是否爲空一般是不會應用索引的，因爲B樹索引(oracle大多是使用B樹索引)是不索引空值的。
優化方案:用其它相同功能的操作運算代替，如 a is not null改爲 a>0 或a>’’等。
is null 時，用一個缺省值代替空值，例如業務申請中狀態字段不允許爲空，缺省爲申請。
LIKE：LIKE操作符可以應用通配符查詢，裏面的通配符組合可能達到幾乎是任意的查詢，
但是如果用得不好則會產生性能上的問題，
優化方案:如LIKE‘%001%’這種查詢不會引用索引，會產生全表掃描，
而LIKE‘001%’則會引用範圍索引。進行範圍的查詢，性能肯定大大提高。
*/
CREATE TABLE emp(
comm INT DEFAULT 0,
status VARCHAR2(18) DEFAULT '申請'
);
CREATE TABLE tb_emp(
emial VARCHAR2(50) DEFAULT 'aaa'
);
SELECT * FROM tb_emp WHERE email IS NULL --不使用index
SELECT * FROM tb_emp WHERE email = 'aaa' --使用index
索引查詢：用user_indexes和user_ind_columns系統表查看已經存在的索引
對於系統中已經存在的索引我們可以通過以下的兩個系統視圖(user_indexes和user_ind_columns)來查看其具體內容，例如是屬於那個表，哪個列和，具體有些什麼參數等等。
--查詢用戶所在表空間
select username,default_tablespace from user_users;
查詢語句select * from ALL_INDEXES where TABLE_NAME=’表名’;可以根據表名查詢到所有表空間的當前表索引信息，包括所屬表空間
其中user_indexes系統視圖存放是索引的名稱以及該索引是否是唯一索引等信息。
而user_ind_column系統視圖則存放的是索引名稱，對應的表和列等。
我們可以通過類似下面的語句來查看一個表的索引的基本情況：
select user_ind_columns.index_name,user_ind_columns.column_name,
user_ind_columns.column_position,user_indexes.uniqueness
from user_ind_columns,user_indexes
where user_ind_columns.index_name = user_indexes.index_name
and user_ind_columns.table_name = ‘你想要查詢的表名字’;
注意：如果根據all_indexes查詢到的表的索引信息tablespace_name和當前登錄數據庫用戶的表空間不一樣，那麼用上訴語句是查不到信息的
（1）選擇最有效率的表名順序(只在基於規則的優化器中有效)：
ORACLE的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫在最後的表(基礎表
driving table)將被最先處理，在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作爲基礎表。如果有3個以上的表連接查詢,那就需要選擇交叉表(intersection
table)作爲基礎表,交叉表是指那個被其他表所引用的表。
（2） WHERE子句中的連接順序：
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前,那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾.
（3） SELECT子句中避免使用 ‘ * ‘：
ORACLE在解析的過程中,會將’*’
依次轉換成所有的列名,
這個工作是通過查詢數據字典完成的,
這意味着將耗費更多的時間。
（4）減少訪問數據庫的次數：
ORACLE在內部執行了許多工作:解析SQL語句,估算索引的利用率,
綁定變量 ,
讀數據塊等。
（5）在SQL*Plus , SQL*Forms和Pro*C中重新設置ARRAYSIZE參數,可以增加每次數據庫訪問的檢索數據量
,建議值爲200。
（6）使用DECODE函數來減少處理時間：
使用DECODE函數可以避免重複掃描相同記錄或重複連接相同的表.
（7）整合簡單,無關聯的數據庫訪問：
如果你有幾個簡單的數據庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關係)
（8）刪除重複記錄：
最高效的刪除重複記錄方法 (因爲使用了ROWID)例子： DELETE FROM EMP
E WHERE E.ROWID > (SELECT MIN(X.ROWID) FROM EMP X WHERE X.EMP_NO = E.EMP_NO)。
（9）用TRUNCATE替代DELETE：
當刪除表中的記錄時,在通常情況下,回滾段(rollback segments )用來存放可以被恢復的信息.如果你沒有COMMIT事務,ORACLE會將數據恢復到刪除之前的狀態(準確地說是恢復到執行刪除命令之前的狀況)而當運用TRUNCATE時,回滾段不再存放任何可被恢復的信息.當命令運行後,數據不能被恢復.因此很少的資源被調用,執行時間也會很短.
(譯者按: TRUNCATE只在刪除全表適用,TRUNCATE是DDL不是DML)。
（10）儘量多使用COMMIT：
只要有可能,在程序中儘量多使用COMMIT,這樣程序的性能得到提高,需求也會因爲COMMIT所釋放的資源而減少:
COMMIT所釋放的資源:
a.
回滾段上用於恢復數據的信息.
b.
被程序語句獲得的鎖
c. redo log buffer中的空間
d. ORACLE爲管理上述3種資源中的內部花費
（11）用Where子句替換HAVING子句：
避免使用HAVING子句, HAVING只會在檢索出所有記錄之後纔對結果集進行過濾.這個處理需要排序,總計等操作.如果能通過WHERE子句限制記錄的數目,那就能減少這方面的開銷.
(非oracle中)on、where、having這三個都可以加條件的子句中，on是最先執行，where次之，having最後，因爲on是先把不符合條件的記錄過濾後才進行統計，它就可以減少中間運算要處理的數據，按理說應該速度是最快的，where也應該比having快點的，因爲它過濾數據後才進行sum，在兩個表聯接時才用on的，所以在一個表的時候，就剩下where跟having比較了。在這單表查詢統計的情況下，如果要過濾的條件沒有涉及到要計算字段，那它們的結果是一樣的，只是where可以使用rushmore技術，而having就不能，在速度上後者要慢如果要涉及到計算的字段，就表示在沒計算之前，這個字段的值是不確定的，根據上篇寫的工作流程，where的作用時間是在計算之前就完成的，而having就是在計算後才起作用的，所以在這種情況下，兩者的結果會不同。在多表聯接查詢時，on比where更早起作用。系統首先根據各個表之間的聯接條件，把多個表合成一個臨時表後，再由where進行過濾，然後再計算，計算完後再由having進行過濾。由此可見，要想過濾條件起到正確的作用，首先要明白這個條件應該在什麼時候起作用，然後再決定放在那裏
（12）減少對錶的查詢：
在含有子查詢的SQL語句中,要特別注意減少對錶的查詢.例子：
SELECT TAB_NAME FROM TABLES WHERE (TAB_NAME,DB_VER) = ( SELECT TAB_NAME,DB_VER FROM TAB_COLUMNS WHERE VERSION = 604)。
（13）通過內部函數提高SQL效率.：
複雜的SQL往往犧牲了執行效率.能夠掌握上面的運用函數解決問題的方法在實際工作中是非常有意義的。
（14）使用表的別名(Alias)：
當在SQL語句中連接多個表時,請使用表的別名並把別名前綴於每個Column上.這樣一來,就可以減少解析的時間並減少那些由Column歧義引起的語法錯誤.
（15）用EXISTS替代IN、用NOT
EXISTS替代NOT IN：
在許多基於基礎表的查詢中,爲了滿足一個條件,往往需要對另一個表進行聯接.在這種情況下,使用EXISTS(或NOT
EXISTS)通常將提高查詢的效率.在子查詢中,NOT IN子句將執行一個內部的排序和合並.無論在哪種情況下,NOT
IN都是最低效的 (因爲它對子查詢中的表執行了一個全表遍歷).爲了避免使用NOT IN ,我們可以把它改寫成外連接(Outer
Joins)或NOT EXISTS. 例子：
（高效）SELECT * FROM EMP (基礎表) WHERE EMPNO > 0 AND EXISTS (SELECT ‘X’ FROM DEPT WHERE DEPT.DEPTNO = EMP.DEPTNO AND LOC
= ‘MELB’) (低效)SELECT * FROM EMP (基礎表) WHERE EMPNO
> 0 AND DEPTNO IN(SELECT DEPTNO FROM DEPT WHERE LOC = ‘MELB’)
（16）識別’低效執行’的SQL語句：
雖然目前各種關於SQL優化的圖形化工具層出不窮,但是寫出自己的SQL工具來解決問題始終是一個最好的方法：
SELECT EXECUTIONS , DISK_READS, BUFFER_GETS, ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio, ROUND(DISK_READS/EXECUTIONS,2)
Reads_per_run, SQL_TEXT
FROM V$SQLAREA
WHERE EXECUTIONS>0 AND BUFFER_GETS > 0 AND
(BUFFER_GETS-DISK_READS)/BUFFER_GETS < 0.8 ORDER BY 4 DESC;
（17）用索引提高效率：
索引是表的一個概念部分,用來提高檢索數據的效率，ORACLE使用了一個複雜的自平衡B-tree結構.通常,通過索引查詢數據比全表掃描要快.當ORACLE找出執行查詢和Update語句的最佳路徑時,
ORACLE優化器將使用索引.同樣在聯結多個表時使用索引也可以提高效率.另一個使用索引的好處是,它提供了主鍵(primary
key)的唯一性驗證.。那些LONG或LONG RAW數據類型,
你可以索引幾乎所有的列.
通常,
在大型表中使用索引特別有效.當然,你也會發現,在掃描小表時,使用索引同樣能提高效率.雖然使用索引能得到查詢效率的提高,但是我們也必須注意到它的代價.索引需要空間來存儲,也需要定期維護,每當有記錄在表中增減或索引列被修改時,索引本身也會被修改.
這意味着每條記錄的INSERT , DELETE , UPDATE將爲此多付出4 , 5次的磁盤I/O
. 因爲索引需要額外的存儲空間和處理,那些不必要的索引反而會使查詢反應時間變慢.。定期的重構索引是有必要的.： ALTER
INDEX <INDEXNAME> REBUILD <TABLESPACENAME>
（18）用EXISTS替換DISTINCT：
當提交一個包含一對多表信息(比如部門表和僱員表)的查詢時,避免在SELECT子句中使用DISTINCT.一般可以考慮用EXIST替換,
EXISTS使查詢更爲迅速,因爲RDBMS核心模塊將在子查詢的條件一旦滿足後,立刻返回結果.例子：
(低效):
SELECT DISTINCT DEPT_NO,DEPT_NAME FROM DEPT D , EMP E WHERE D.DEPT_NO = E.DEPT_NO
(高效):
SELECT DEPT_NO,DEPT_NAME FROM DEPT D WHERE EXISTS ( SELECT ‘X’ FROM EMP E WHERE E.DEPT_NO = D.DEPT_NO);
（19） sql語句用大寫的；因爲oracle總是先解析sql語句，把小寫的字母轉換成大寫的再執行
（20）在java代碼中儘量少用連接符“＋”連接字符串！
（21）避免在索引列上使用NOT通常，我們要避免在索引列上使用NOT,
NOT會產生在和在索引列上使用函數相同的影響.當ORACLE”遇到”NOT,他就會停止使用索引轉而執行全表掃描.
（22）避免在索引列上使用計算．WHERE子句中，如果索引列是函數的一部分．優化器將不使用索引而使用全表掃描．
舉例:
低效： SELECT … FROM DEPT WHERE SAL * 12 > 25000;
高效:
SELECT … FROM DEPT WHERE SAL > 25000/12;
（23）用>=替代>
高效:
SELECT * FROM EMP WHERE DEPTNO >=4
低效:
SELECT * FROM EMP WHERE DEPTNO >3 兩者的區別在於,
前者DBMS將直接跳到第一個DEPT等於4的記錄而後者將首先定位到DEPTNO=3的記錄並且向前掃描到第一個DEPT大於3的記錄.
（24）用UNION替換OR
(適用於索引列)通常情況下,用UNION替換WHERE子句中的OR將會起到較好的效果.對索引列使用OR將造成全表掃描.注意,
以上規則只針對多個索引列有效.
如果有column沒有被索引,查詢效率可能會因爲你沒有選擇OR而降低.在下面的例子中,
LOC_ID和REGION上都建有索引.
高效:
SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE
LOC_ID = 10 UNION
SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE
REGION = “MELBOURNE”
低效:
SELECT LOC_ID , LOC_DESC , REGION FROM LOCATION WHERE
LOC_ID = 10 OR REGION = “MELBOURNE” 如果你堅持要用OR,那就需要返回記錄最少的索引列寫在最前面.
（25）用IN來替換OR
這是一條簡單易記的規則，但是實際的執行效果還須檢驗，在ORACLE8i下，兩者的執行路徑似乎是相同的．
低效:
SELECT…. FROM LOCATION WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30
高效：
SELECT… FROM LOCATION WHERE LOC_IN IN (10,20,30);
（26）避免在索引列上使用IS NULL和IS
NOT NULL 避免在索引中使用任何可以爲空的列，ORACLE將無法使用該索引．對於單列索引，如果列包含空值，索引中將不存在此記錄.對於複合索引，如果每個列都爲空，索引中同樣不存在此記錄. 如果至少有一個列不爲空，則記錄存在於索引中．舉例:如果唯一性索引建立在表的A列和B列上,並且表中存在一條記錄的A,B值爲(123,null)
, ORACLE將不接受下一條具有相同A,B值（123,null）的記錄(插入).然而如果所有的索引列都爲空，ORACLE將認爲整個鍵值爲空而空不等於空.因此你可以插入1000條具有相同鍵值的記錄,當然它們都是空!因爲空值不存在於索引列中,所以WHERE子句中對索引列進行空值比較將使ORACLE停用該索引. 低效:
(索引失效)
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL; 高效: (索引有效) SELECT
… FROM DEPARTMENT WHERE DEPT_CODE >=0;
（27）總是使用索引的第一個列：如果索引是建立在多個列上,只有在它的第一個列(leading
column)被where子句引用時,優化器纔會選擇使用該索引.這也是一條簡單而重要的規則，當僅引用索引的第二個列時,優化器使用了全表掃描而忽略了索引。
（28）用UNION-ALL替換UNION
( 如果有可能的話)：當SQL語句需要UNION兩個查詢結果集合時,這兩個結果集合會以UNION-ALL的方式被合併,然後在輸出最終結果前進行排序.如果用UNION
ALL替代UNION,這樣排序就不是必要了.效率就會因此得到提高.需要注意的是，UNION
ALL將重複輸出兩個結果集合中相同記錄.因此各位還是要從業務需求分析使用UNION ALL的可行性.
UNION將對結果集合排序,這個操作會使用到SORT_AREA_SIZE這塊內存.對於這塊內存的優化也是相當重要的.下面的SQL可以用來查詢排序的消耗量
低效：
SELECT ACCT_NUM, BALANCE_AMT FROM DEBIT_TRANSACTIONS WHERE
TRAN_DATE = ’31-DEC-95’ UNION
SELECT ACCT_NUM, BALANCE_AMT FROM DEBIT_TRANSACTIONS WHERE
TRAN_DATE = ’31-DEC-95’
高效:
SELECT ACCT_NUM, BALANCE_AMT FROM DEBIT_TRANSACTIONS WHERE
TRAN_DATE = ’31-DEC-95’ UNION ALL SELECT ACCT_NUM, BALANCE_AMT FROM
DEBIT_TRANSACTIONS WHERE TRAN_DATE = ’31-DEC-95’
（29）用WHERE替代ORDER
BY： ORDER BY子句只在兩種嚴格的條件下使用索引. ORDER BY中所有的列必須包含在相同的索引中並保持在索引中的排列順序. ORDER
BY中所有的列必須定義爲非空. WHERE子句使用的索引和ORDER BY子句中所使用的索引不能並列.
例如:
表DEPT包含以下列: DEPT_CODE PK NOT NULL DEPT_DESC
NOT NULL DEPT_TYPE NULL
低效: (索引不被使用) SELECT DEPT_CODE FROM DEPT ORDER
BY DEPT_TYPE
高效: (使用索引) SELECT DEPT_CODE FROM DEPT WHERE
DEPT_TYPE > 0
（30）避免改變索引列的類型.: 當比較不同數據類型的數據時,
ORACLE自動對列進行簡單的類型轉換. 假設 EMPNO是一個數值類型的索引列. SELECT
… FROM EMP WHERE EMPNO = ‘123’ 實際上,經過ORACLE類型轉換,語句轉化爲:
SELECT … FROM EMP WHERE EMPNO = TO_NUMBER(‘123’) 幸運的是,類型轉換沒有發生在索引列上,索引的用途沒有被改變. 現在,假設EMP_TYPE是一個字符類型的索引列. SELECT
… FROM EMP WHERE EMP_TYPE = 123 這個語句被ORACLE轉換爲: SELECT
… FROM EMP WHERETO_NUMBER(EMP_TYPE)=123 因爲內部發生的類型轉換,這個索引將不會被用到!爲了避免ORACLE對你的SQL進行隱式的類型轉換,最好把類型轉換用顯式表現出來.注意當字符和數值比較時,
ORACLE會優先轉換數值類型到字符類型。
（31）需要當心的WHERE子句:某些SELECT語句中的WHERE子句不使用索引.這裏有一些例子.
在下面的例子裏,
(1)‘!=’ 將不使用索引.記住,索引只能告訴你什麼存在於表中,
而不能告訴你什麼不存在於表中.
(2) ‘||’是字符連接函數.就象其他函數那樣,
停用了索引.
(3) ‘+’是數學函數.就象其他數學函數那樣,停用了索引.
(4)相同的索引列不能互相比較,這將會啓用全表掃描.
（32）
a. 如果檢索數據量超過30%的表中記錄數.使用索引將沒有顯著的效率提高.
b. 在特定情況下,
使用索引也許會比全表掃描慢,
但這是同一個數量級上的區別.
而通常情況下,使用索引比全表掃描要塊幾倍乃至幾千倍!
（33）避免使用耗費資源的操作: 帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER
BY的SQL語句會啓動SQL引擎 執行耗費資源的排序(SORT)功能.
DISTINCT需要一次排序操作,而其他的至少需要執行兩次排序.通常,
帶有UNION, MINUS , INTERSECT的SQL語句都可以用其他方式重寫.如果你的數據庫的SORT_AREA_SIZE調配得好,使用UNION
, MINUS, INTERSECT也是可以考慮的,畢竟它們的可讀性很強。
（34）優化GROUP BY: 提高GROUP
BY 語句的效率,
可以通過將不需要的記錄在GROUP BY之前過濾掉.下面兩個查詢返回相同結果但第二個明顯就快了許多.
低效:
SELECT JOB , AVG(SAL) FROM EMP
GROUP BY JOB
HAVING JOB = ‘PRESIDENT’ OR JOB = ‘MANAGER’
高效:
SELECT JOB , AVG(SAL) FROM EMP
WHERE JOB = ‘PRESIDENT’ OR JOB = ‘MANAGER’ GROUP
BY JOB
