引起索引失效的原因和解決方法

一、以下的方法會引起索引失效
‍1,<>
2,單獨的>,<,(有時會用到，有時不會)
3,like "%_" 百分號在前.
4,表沒分析.
5,單獨引用複合索引裡非第一位置的索引列.
6,字元型欄位為數字時在where條件裡不新增引號.
7,對索引列進行運算.需要建立函式索引.
8,not in ,not exist.
9,當變數採用的是times變數，而表的欄位採用的是date變數時.或相反情況。
10, 索引失效。
11,基於cost成本分析(oracle因為走全表成本會更小)：查詢小表,或者返回值大概在10%以上
12,有時都考慮到了 但就是不走索引,drop了從建試試在
13,B-tree索引 is null不會走,is not null會走,點陣圖索引 is null,is not null   都會走
14,聯合索引 is not null 只要在建立的索引列（不分先後）都會走, 
in null時   必須要和建立索引第一列一起使用,當建立索引第一位置條件是is null 時,其他建立索引的列可以是is null（但必須在所有列都滿足is null的時候）,或者=一個值；
當建立索引的第一位置是=一個值時,其他索引列可以是任何情況（包括is null =一個值）,以上兩種情況索引都會走。其他情況不會走。
二、索引失效解決方法
1. 選用適合的Oracle優化器
Oracle的優化器共有3種:
a. RULE (基於規則) b. COST (基於成本) c. CHOOSE (選擇性)。
設定預設的優化器,可以通過對init.ora檔案中OPTIMIZER_MODE引數的各種宣告,如RULE，COST，CHOOSE，ALL_ROWS，FIRST_ROWS 。你當然也在SQL句級或是會話(session)級對其進行覆蓋。
為了使用基於成本的優化器(CBO, Cost-Based Optimizer) , 你必須經常執行analyze 命令,以增加資料庫中的物件統計資訊(object statistics)的準確性。
如果資料庫的優化器模式設定為選擇性(CHOOSE),那麼實際的優化器模式將和是否執行過analyze命令有關。如果table已經被analyze過, 優化器模式將自動成為CBO , 反之,資料庫將採用RULE形式的優化器。
（分析table
analyze table PROD_PARTS compute statistics;
ANALYZE TABLE PROD_PARTS COMPUTE STATISTICS FOR ALL INDEXED COLUMNS;
analyze table PROD_PARTS compute statistics for table for all indexes for all indexed columns;
）
在預設情況下,Oracle採用CHOOSE優化器, 為了避免那些不必要的全表掃描（full table scan）, 你必須儘量避免使用CHOOSE優化器,而直接採用基於規則或者基於成本的優化器。
2、‍重建索引 
‍alter index 索引名 rebuild
3、強制索引
給該語句加上hint後，強制其使用'RECORD_ENTITYID' 這個索引
sql語句變成這樣
引用
select /*+ index(record,record_entityid) */ *
from RECORD
where entityId='24' and entityType='blog';
/*+ index(record,record_entityid) */ 中，index表示強制使用index，record是表名，record_entityid是索引名。其執行計劃跟測試資料庫上一致，都是使用用 'RECORD_ENTITYID' 這個索引，邏輯讀寫同樣為4。
後來經過測試，在不加hint的情況下，對該表和兩個索引執行analyze 後，同樣也能使用 'RECORD_ENTITYID' 這個索引。但是因為該表更新頗為頻繁，不知道要多久就要再分析一次