索引失效快速記憶

索引失效快速記憶

　　

　　索引在平時資料庫使用中會被我們經常用到，索引在查詢的時候使用不當，這會嚴重影響到我們伺服器資料查詢的性能（主要是客戶對系統的評價），那麼索引失效的原因有哪些啦？如何能夠快速記憶？

　　有一個口訣：[模型函][空運][最快](某種模型[索引失效]的信函、函件，隻有空運才能最快到達目的地)，下面将分别介紹每個字背後的意義。

　　模（模糊查詢）：like的模糊查詢以%開頭，索引失效。比如：SELECT * FROM `room_info` WHERE `room_name` LIKE '%1-10%';

　　型（資料類型不比對）：類型錯誤，如字段類型為varchar，where條件後的用number，索引也會失效。比如：SELECT * FROM `room_info` WHERE room_no= 101; room_no房間編号為varchar類型，查詢使用integer類型導緻索引失效。

　　函（查詢索引字段使用函數）：對索引的字段使用内部函數，索引也會失效。這種情況下應該建立基于函數的索引。比如：SELECT * FROM `room_info` WHERE DATE(create_time) = '2020-09-03';create_time字段設定索引，那就無法使用函數，否則索引失效。

　　空（查詢索引字段值為Null值）：索引不應該存儲空值，如果不限制索引列是not null，資料庫會認為索引列有可能存在空值，是以不會按照索引進行計算。

　　　　比如：

　　　　SELECT * FROM `room_info` WHERE address IS NULL;不走索引。　　

　　　　SELECT * FROM `room_info` WHERE address IS NOT NULL;走索引。　　

　　　　建議大家這設計字段的時候，如果沒有必要的要求必須為NULL，那麼最好給個預設值空字元串（或者預設值），這可以解決很多後續的麻煩（切記）。

　　運（對查詢字段進行運算）：對索引列進行（+，-，*，/，!, !=, <>）等運算，會導緻索引失效。比如：SELECT * FROM `room_owner` WHERE age - 1 = 20;

　　最（不遵循最左比對原則）：在複合索引中索引列的順序至關重要。如果不是按照索引的最左列開始查找，則無法使用索引。

　　快（全表掃描比走索引速度更快）：如果資料庫預計使用全表掃描要比使用索引快，則不使用索引。

說明：以上索引失效的口訣主要是針對關系型資料庫，newSQL資料庫如TIDB、OceanBase等需要根據自身索引要求單獨研究。