1．隱式轉換導致索引失效.這一點應當引起重視.也是開發中經常會犯的錯誤.
由於表的字段tu_mdn定義為varchar2(20),但在查詢時把該字段作為number型別以where條件傳給oracle,這樣會導致索引失效.
錯誤的例子：select * from test where tu_mdn=13333333333;
正確的例子：select * from test where tu_mdn=『13333333333』;
2. 對索引列進行運算導致索引失效,我所指的對索引列進行運算包括(+，-，*，/，! 等)
錯誤的例子：select * from test where id-1=9;
正確的例子：select * from test where id=10;
3. 使用oracle內部函式導致索引失效.對於這樣情況應當建立基於函式的索引.
錯誤的例子：select * from test where round(id)=10; 說明，此時id的索引已經不起作用了
4. 以下使用會使索引失效，應避免使用；
a. 使用 <> 、not in 、not exist、!=
b. like 「%_」 百分號在前（可採用在建立索引時用reverse(columnname)這種方法處理）
c. 單獨引用復合索引裡非第一位置的索引列.應總是使用索引的第乙個列，如果索引是建立在多個列上, 只有在它的第乙個列被where子句引用時，優化器才會選擇使用該索引。
d. 字元型字段為數字時在where條件裡不新增引號.
e. 當變數採用的是times變數，而表的字段採用的是date變數時.或相反情況。
5. 不要將空的變數值直接與比較運算子（符號）比較。
如果變數可能為空，應使用 is null 或 is not null 進行比較，或者使用 isnull 函式。
6. 不要在 sql **中使用雙引號。
因為字元常量使用單引號。如果沒有必要限定物件名稱，可以使用（非 ansi sql 標準）括號將名稱括起來。
索引使用原則：
在根據執行計畫對sql進行分析之後，逐步的去優化每個子查詢的索引及成本使用情況，執行計畫我的理解就是用來對索引進行逐步的優化的乙個過程，讓每個查詢都盡量使用索引，在索引過程中，索引會經常性失效。
口訣
全值匹配我最愛，最左字首要遵守
帶頭大哥不能死，中間兄弟不能斷
索引列上少計算，範圍之後全失效
like符號寫最右，覆蓋索引不寫星
不等空值還有or，索引失效要少用
var引號不能丟，sql高階也不難
分組之前必排序，一定要上索引啊
1、單值索引，盡量選擇過濾性更好的字段，例如：性別字段，過濾度為50%，識別率很差，不建議建索引
2、組合索引，索引欄位的順序可以按照識別度進行排序，識別度越高，放在越靠前
3、組合索引，盡量包含where語句中的更多字段
4、盡可能的根據分析執行計畫、統計資訊，去調整query的寫法達到合適索引的目的
索引容易失效的幾個注意點
1、不在索引列上做任何的操作（計算、函式、型別轉換），會導致索引失效而轉向全表掃瞄
2、組合索引中，如果中間某個字段使用了範圍條件，則右邊的列索引失效
3、盡量使用覆蓋索引（索引列和查詢列一致），減少使用select *
4、mysql在使用不等於（！= 或者<>）的時候，無法使用索引列會導致全表掃瞄
5、is null ，is not null 也無法使用索引
6、like萬用字元必須放在索引列的右邊，否則索引失效，程式設計全表掃瞄
7、字串不加單引號索引失效
8、少用or，用它連線索引會失效
like索引失效原因 索引失效的情況及原因定位
同事遇到乙個奇葩的問題，乙個表裡某個欄位建了索引，但是有的值走索引，有的值不走索引。因為一般情況乙個字段要麼完全不走索引，要麼走索引，怎麼會有的值走索引，有的不走索引。select 條件非常簡單，因為涉及到敏感資訊就不貼表結構了。例如select from order where status 2 ...
索引失效原因分類
1 沒有查詢條件，或者查詢條件沒有建立索引 2 在查詢條件上沒有使用復合索引引導列 3 查詢的資料量超過了表資料量的15 4 索引本身失效 status unusable 5 查詢條件使用函式在索引列上 6 對小表查詢 7 使用hint提示不使用索引 8 統計資訊不真實 9 cbo認為走全表掃瞄比走...
索引失效原因總結
今天乙個同事突然問我索引為什麼失效。說實在的，失效的原因有多種 但是如果是同樣的sql如果在之前能夠使用到索引，那麼現在使用不到索引，以下幾種主要情況 1.隨著表的增長，where條件出來的資料太多，大於15 使得索引失效 會導致cbo計算走索引花費大於走全表 2.統計資訊失效 需要重新蒐集統計資訊...