MySQL的IN子句为什么有时不走索引_调整eq_range_index_dive_limit参数

IN子句不走索引主因是MySQL优化器为避免高开销的index dive而启用eq_range_index_dive_limit阈值机制：5.7默认200、8.0默认10，超限则改用统计估算致误判全表扫描；调参需会话级谨慎设值并配合ANALYZE TABLE及类型对齐、索引设计等根本优化。

IN子句不走索引，往往不是SQL写错了，而是MySQL优化器主动放弃了range访问路径——eq_range_index_dive_limit就是那个关键开关。

为什么调eq_range_index_dive_limit能影响IN是否走索引

MySQL在决定是否对IN使用索引时，会对每个IN值做“index dive”（索引下潜），估算匹配行数。但这个操作代价高，所以设了硬性上限：eq_range_index_dive_limit默认是200（5.7）或10（8.0）。一旦IN列表长度超过该值，优化器就跳过逐个探测，改用统计信息粗略估算——常误判为“全表扫描更便宜”，于是type=all。

这不是bug，是权衡：避免小查询被大量index dive拖慢，但代价是大IN列表大概率丢索引。

• 该参数只影响IN、=、BETWEEN等等值/范围条件的索引选择，不影响LIKE 'abc%'这类前缀扫描
• 修改后仅对新执行的查询生效，已缓存的执行计划不会自动刷新
• 8.0中默认值激进（10），比5.7（200）更容易触发退化，升级后要特别注意

怎么安全地调整eq_range_index_dive_limit

直接SET GLOBAL有风险，建议按需局部调整：

• 会话级临时调高（推荐）：SET SESSION eq_range_index_dive_limit = 500;，之后再跑IN查询
• 不要盲目设太大（如10000），否则单次查询可能卡住，尤其当IN值对应索引碎片严重时
• 配合ANALYZE TABLE一起用，确保统计信息不过期——失真的基数会让调高该值也无效
• 查当前值：SELECT @@session.eq_range_index_dive_limit;

eq_range_index_dive_limit之外，IN不走索引的常见干扰项

别只盯着这个参数，以下问题会让调再大也没用：

• IN里混了NULL，如WHERE status IN (1, 2, NULL) → 优化器直接剪枝索引路径
• 字段类型和IN值类型不一致，比如user_id INT却写IN ('1001', '1002') → 隐式转换让索引失效
• 复合索引下跳过了最左列，如索引是(a,b,c)，但写了WHERE b IN (1,2) AND c = 3 → 根本用不到索引
• IN值在索引中分布极偏（比如95%都是同一个值），优化器算下来回表成本太高，宁可全扫

真正要稳住IN走索引，得先确认EXPLAIN里type是range、key有具体索引名、rows预估合理；参数只是辅助，类型匹配、数据分布、索引设计才是根基。