雖然你這列上建了索引，查詢條件也是索引列，但最終執行計划沒有走它的索引。
下面是引起這種問題的幾個關鍵點。
列與列對比
某個表中，有兩列（id和c_id）都建了單獨索引，下面這種查詢條件不會走索引
這種情況會被認為還不如走全表掃描。
存在NULL值條件
我們在設計數據庫表時，應該盡力避免NULL值出現，如果非要不可避免的要出現NULL值，也要給一個DEFAULT值，數值型可以給0、-1之類的， 字符串有時候給空串有問題，就給一個空格或其他。如果索引列是可空的，是不會給其建索引的，索引值是少於表的count(*)值的，所以這種情況下，執行計划自然就去掃描全表了。
NOT條件
我們知道建立索引時，給每一個索引列建立一個條目，如果查詢條件為等值或范圍查詢時，索引可以根據查詢條件去找對應的條目。反過來當查詢條件為非時，索引定位就困難了，執行計划此時可能更傾向於全表掃描，這類的查詢條件有：<>、NOT、in、not exists
LIKE通配符
當使用模糊搜索時，盡量采用后置的通配符，例如：name||’%’，因為走索引時，其會從前去匹配索引列，這時候是可以找到的，如果采用前匹配，那么查索引就會很麻煩，比如查詢所有姓張的人，就可以去搜索’張%’。
相反如果你查詢所有叫‘明’的人，那么只能是%明。這時候索引如何定位呢？前匹配的情況下，執行計划會更傾向於選擇全表掃描。后匹配可以走INDEX RANGE SCAN。
所以業務設計的時候，盡量考慮到模糊搜索的問題，要更多的使用后置通配符。
條件上包括函數
查詢條件上盡量不要對索引列使用函數，比如下面這個SQL
這樣是不會走索引的，因為索引在建立時會和計算后可能不同，無法定位到索引。但如果查詢條件不是對索引列進行計算，那么依然可以走索引。比如
這樣的函數還有：to_char、to_date、to_number、trunc等
復合索引前導列區分大
當復合索引前導列區分小的時候，我們有INDEX SKIP SCAN，當前導列區分度大，且查后導列的時候，前導列的分裂會非常耗資源，執行計划想，還不如全表掃描來的快，然后就索引失效了。
數據類型的轉換
當查詢條件存在隱式轉換時，索引會失效。
比如在數據庫里id存的number類型，但是在查詢時，卻用了下面的形式：
Connect By Level
使用connect by level時，不會走索引。
謂詞運算
我們在上面說，不能對索引列進行函數運算，這也包括加減乘除的謂詞運算，這也會使索引失效。
建立一個sunyang表，索引為id，看這個SQL：
這里很明顯對索引列id進行了’/2’除二運算，這時候就會索引失效，這種情況應該改寫為：
就可以使用索引了。
Vistual Index
先說明一下，虛擬索引的建立是否有用，需要看具體的執行計划，如果起作用就可以建一個，如果不起作用就算了。普通索引這么建：
虛擬索引Vistual Index這么建：
做了一個實驗，首先創建一個表：
其中id為普通索引，a為虛擬索引。
在表中插入十萬條數據
接着分別去執行下面的SQL看時間，由於在內網機做實驗，圖貼不出來，數據保證真實性。
因為在執行過一次后，oracle對結果集緩存了，所以第二次執行耗時不走索引，走內存就都一樣了。
可以看到在這種情況下，虛擬索引比普通索引快了一倍。
具體虛擬索引的使用細節，這里不再展開討論。
Invisible Index
Invisible Index是oracle 11g提供的新功能，對優化器（還接到前面博客里講到的CBO嗎）不可見，MySQL 也有，MySQL 8.0 中的索引可以隱藏了。我感覺這個功能更主要的是測試用，假如一個表上有那么多索引，一個一個去看執行計划調試就很慢了，這時候不如建一個對表和查詢都沒有影響的Invisible Index來進行調試，就顯得很好了。
通過下面的語句來操作索引
如果想讓CBO看到Invisible Index，需要加入這句：
