簡單的in查詢 索引失效：

步驟

1、檢查建立索引沒有

order_status 字段為普通索引的tinyint類型

2、檢查是否使用了使索引失效的語句

3、explain查看執行計劃

而 in(1)時會走索引

5、查看是否關閉的全局的索引(Comment顯示disabled則表示關閉了索引)

SHOW KEYS FROM wy_order;

關閉：ALTER TABLE `wy_order` DISABLE KEYS ;

開啟：ALTER TABLE `wy_order` ENABLE KEYS;

還找不到原因。。

難道是mysql查詢優化器認為全表掃描時如果速度大于使用索引，就會不用索引

此外，查看索引的使用情況

show status like ‘Handler_read%';

注意：

handler_read_key:這個值越高越好，越高表示使用索引查詢到的次數

handler_read_rnd_next:這個值越高，說明查詢低效

那么使用強制索引呢

強制索引是生效的，求大佬告知(是mysql查詢優化器認為全表掃描時如果速度大于使用索引，就會不用索引)是不是我猜想的這樣呀

補充：索引失效

不走索引的情況，1)被查詢出來的數據超過一定比例的時候，譬如表里有1000萬條記錄，一條SQL查的結果有600萬，肯定不會走索引了2)索引列上用了函數的時候，例如where to_char(id) = ...

3)索引列上發生類型轉換的時候，如number列你偏寫成where col = '1',加了引號4)沒有收集統計信息的時候，CBO是生成執行計劃是要看統計信息的，在oracle 9i時，統計信息不是自動收集的，有沒有碰到這樣的情況：一條SQL一直正常，某天突然很慢很慢，一般就是統計信息沒有收集的原因。5)強制全表掃描的時候6)索引失效的時候 使用+ - * / ! 等運算符號 使用 <> 、not in 、not exist、!=

like "%_" 百分號在前(可采用在建立索引時用reverse(columnName)這種方法處理)

單獨引用復合索引里非第一位置的索引列.應總是使用索引的第一個列，如果索引是建立在多個列上, 只有在它的第一個列被where子句引用時，優化器才會選擇使用該索引

當變量采用的是times變量，而表的字段采用的是date變量時.或相反情況

索引列存在null7)復合索引時，謂詞非前導列的時候

總結

以上是生活随笔為你收集整理的mysql in or索引失效_in 索引失效的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。