关于MySQL种的in函数到底走不走索引、我和同事差点大打出手！
背景：有一天同事突然问我为什么加了in查询就突然变慢了、小羊脱口而出：“in不走索引!” 于是就炸开了锅：in不走索引！怎么可能？ 但是在小羊同学脑子里、in不走索引为什么早就根深固体了？原因暂且不说，我们来探索真像。
环境：Windows10、MySQL5.7、可视化工具navicat。
场景1：当IN中的取值只有一个主键时
我们只需要注意一个最重要的type 的信息很明显的提现是否用到索引：
type：连接类型（建议记到小本本上）
-
system：表只有一行记录，相当于系统表
-
const：通过索引一次就找到，只匹配一行数据
-
eq_ref: 唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配
-
ref：非唯一性索引扫描，返回匹配某个单独值的所有行用于=、<、> 操作符带索引的列
-
range：只检索给定范围的行，使用一个索引来选择行一般使用 between、<、>
-
index：只遍历索引树
-
ALL：全表扫描，性能最差
场景2：扩大IN中的取值范围
此时仍然走了索引，但是效率明显降低了
场景3：继续扩大IN的取值范围
发现此时已经没有走索引了，而是全表扫描
结论：
当数据量很大的时候，in("大量数据")，in 查询走索引也许不是最好的
但是！
当查询的列是char类型，必须加""号才可走索引，否则导致全表扫描，会随着表的增大而变得更慢
结论：
-
当in()种的数据很大时，不走索引
-
当查询的列是char类型没有加引号，mysql优化器会自动给填充引号，同时也会导致索引失效
-
当in()中存在子查询、格式化函数等同样也会使索引失效！
-
