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预估合理；参数只是辅助，类型匹配、数据分布、索引设计才是根基。
