結論：IN確定會走索引，可是當IN的取值範圍較大時會致使索引失效，走全表掃描mysql
navicat可視化工具使用explain函數查看sql執行信息sql
場景1：當IN中的取值只有一個主鍵時mysql優化
咱們只須要注意一個最重要的type 的信息很明顯的提現是否用到索引：函數
type結果值從好到壞依次是：工具
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL優化
all:全表掃描spa
index:另外一種形式的全表掃描，只不過他的掃描方式是按照索引的順序3d
range：有範圍的索引掃描，相對於index的全表掃描，他有範圍限制，所以要優於indexblog
ref: 查找條件列使用了索引並且不爲主鍵和unique。其實，意思就是雖然使用了索引，但該索引列的值並不惟一，有重複。這樣即便使用索引快速查找到了第一條數據，仍然不能中止，要進行目標值附近的小範圍掃描。但它的好處是它並不須要掃全表，由於索引是有序的，即使有重複值，也是在一個很是小的範圍內掃描。索引
const:一般狀況下，若是將一個主鍵放置到where後面做爲條件查詢，mysql優化器就能把此次查詢優化轉化爲一個常量。至於如何轉化以及什麼時候轉化，這個取決於優化器
通常來講，得保證查詢至少達到range級別，最好能達到ref，type出現index和all時，表示走的是全表掃描沒有走索引，效率低下，這時須要對sql進行調優。
當extra出現Using filesor或Using temproary時，表示沒法使用索引，必須儘快作優化。
possible_keys：sql所用到的索引
key：顯示MySQL實際決定使用的鍵（索引）。若是沒有選擇索引，鍵是NULL
rows: 顯示MySQL認爲它執行查詢時必須檢查的行數。
場景2：擴大IN中的取值範圍
此時仍然走了索引，可是效率下降了
場景3：繼續擴大IN的取值範圍
發現此時已經沒有走索引了，而是全表掃描