结论：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的取值范围
发现此时已经没有走索引了，而是全表扫描