1.索引列不要使用函數和運算
2. 盡量避免使用 != 或 not in或 <> 等否定操作符
3.當查詢條件為多個的時候，可以采用復合索引
4.范圍查詢對多列查詢的影響
? ?查詢中的某個列有范圍查詢，則其右邊所有列都無法使用索引優化查找。
舉個例子，假設有一個場景需要查詢本周發布的資訊文章，其中的條件是必須是啟用狀態，且發布時間在這周內。那么，SQL 語句可以寫成：
select*fromnewswherepublish_time >='2017-01-02'andpublish_time <='2017-01-08'andenable=1
這種情況下，因為范圍查詢對多列查詢的影響，將導致 news_publish_idx(publish_time, enable) 索引中 publish_time 右邊所有列都無法使用索引優化查找。換句話說，news_publish_idx(publish_time, enable) 索引等價于 news_publish_idx(publish_time) 。
對于這種情況，我的建議：對于范圍查詢，務必要注意它帶來的副作用，并且盡量少用范圍查詢，可以通過曲線救國的方式滿足業務場景。
5.遵循最左匹配原則
? ?復合索引遵守“最左前綴”原則，即在查詢條件中使用了復合索引的第一個字段，索引才會被使用。因此，在復合索引中索引列的順序至關重要。如果不是按照索引的最左列開始查找，則無法使用索引。
6.索引列不會包含NULL值
7.盡量避免使用 or 來連接條件
8.隱式轉換的影響
? ?當查詢條件左右兩側類型不匹配的時候會發生隱式轉換，隱式轉換帶來的影響就是可能導致索引失效而進行全表掃描。下面的案例中，date_str 是字符串，然而匹配的是整數類型，從而發生隱式轉換。
select*fromnewswheredate_str =201701
9.like 語句的索引失效問題
like 的方式進行查詢，在 like "value%" 可以使用索引，但是對于 like "%value%" 這樣的方式，執行全表查詢，這在數據量小的表，不存在性能問題，但是對于海量數據，全表掃描是非常可怕的事情。所以，根據業務需求，考慮使用
