昨天碰到乙個很有意思的問題，乙個sql 語句，加上 softuseline like '%oqc%' 之後，速度就特別慢。去掉該條件之後，速度就快起來了。
檢視sql 語句的執**況，發現加上那個查詢條件之後，softwaredetailinfo表的邏輯讀取變成了1300374 次，
可是這個查詢字段明明已經加上index_softwaredetail索引了，怎麼會邏輯讀取還這麼大呢。檢視sql profile 的詳細資訊，發現sql 語句，沒有走那個索引。
於是，加上with(index(index_softwaredetail)) ，讓sql 必須走這個索引試試。sql查詢立馬變快了。sql profile 顯示，已經走了index_softwaredetail索引。看來是索引建立的有問題，導致查詢計畫，沒有走該索引，而是進行全表掃瞄。所以導致查詢速度變慢。
於是把所有索引重新調整下。ok了。
資料庫中索引什麼時候會失效呢?
總結下資料庫中索引失效的問題，不過有些沒有經過測試。這裡僅供自己參考。
首先，所謂失效。並不真的就是這個索引被刪除了。而是在某些情況下，dbms不會檢索索引列表了。執行速度和沒有這個索引時的速度一樣。但是再執行另外的一條語句。同樣的索引又正常起作用。所以索引的失效是針對某條sql語句，某個查詢條件的，而不是針對索引本身的。
哪類語句執行時索引不起作用呢。總結如下：
1. 索引字段進行判空查詢時。也就是對索引字段判斷是否為null時。語句為is null 或is not null。
比如：select * from softwaredetailinfo where createtime is null 此時就不檢索time欄位上的索引表了。也就是索引在這條語句執行時失效了。
接著再執行
select * from softwaredetailinfo where createtime = '2015-04-11 00:00:00' 此時就會檢索索引表了。索引又起作用了。
2. 對索引字段進行like查詢時。比如：select * from softwaredetailinfo where softuseline like '%oqc%'。不過網上有的例子說like 'xx%'索引起作用。我沒試過。
3. 判斷索引列是否不等於某個值時。『!=』操作符。比如：select * from softwaredetailinfo where softuseline != 0
4. 對索引列進行運算。這裡運算包括+-*/等運算。也包括使用函式。比如：
select * from softwaredetailinfo where softuseline +0= 0
此時索引不起作用。
select * from softwaredetailinfo where count(softuseline) = 0
此時索引也不起作用。
也就是說如果不是直接判斷索引欄位列，而是判斷運算或其它函式處理後的索引列索引均不起作用。
5. 復合索引中的前導列沒有被作為查詢條件。比如：index_softwaredetail索引包含（a，b，c） 三列，但是查詢條件裡面，沒有a，b 列，只有c 列，那麼 index_softwaredetail索引也不起作用，但是用a或a,b或a,b,c作為條件時都可以使用該索引，即第乙個索引字段必須使用，查詢是索引才會有效。
記錄資料庫中索引失效的問題
昨天碰到乙個很有意思的問題，乙個sql 語句，加上 softuseline like oqc 之後，速度就特別慢。去掉該條件之後，速度就快起來了。檢視sql 語句的執 況，發現加上那個查詢條件之後，softwaredetailinfo表的邏輯讀取變成了1300374 次，可是這個查詢字段明明已經加上...
記錄資料庫中索引失效的問題
昨天碰到乙個很有意思的問題，乙個sql 語句，加上 softuseline like oqc 之後，速度就特別慢。去掉該條件之後，速度就快起來了。檢視sql 語句的執 況，發現加上那個查詢條件之後，softwaredetailinfo表的邏輯讀取變成了1300374 次，可是這個查詢字段明明已經加上...
記錄資料庫中索引失效的問題
昨天碰到乙個很有意思的問題，乙個sql 語句，加上 softuseline like oqc 之後，速度就特別慢。去掉該條件之後，速度就快起來了。檢視sql 語句的執 況，發現加上那個查詢條件之後，softwaredetailinfo表的邏輯讀取變成了1300374 次，可是這個查詢字段明明已經加上...