日常排查MySQL慢查询时，经常遇到这样的困惑：IN子句明明有索引可用，优化器却偏偏选择了全表扫描。很多人的第一反应是SQL语句写错了，或者索引没有正确建立，但反复检查后发现并非如此。实际上，问题根源很可能出在MySQL优化器的一个关键参数上——eq_range_index_dive_limit。这个参数控制着优化器是精确地对每个IN值执行索引探测，还是直接基于统计信息进行估算。一旦IN列表中的元素数量超过预设阈值，优化器就可能错误地判定全表扫描成本更低，从而主动放弃索引路径，导致性能大幅下降。
IN子句不走索引，原因往往不在于SQL语句的写法，而是MySQL优化器自行放弃了range访问路径——eq_range_index_dive_limit正是决定这一行为的关键参数。
为什么调eq_range_index_dive_limit能影响IN是否走索引
MySQL在决定是否对IN条件使用索引时，会针对列表中的每个值执行一次"index dive"（索引下潜），以精确估算匹配的行数。这一机制虽然结果准确，但代价较高——每个IN值都需要深入B+树进行遍历。为此，MySQL设置了一个硬性阈值：eq_range_index_dive_limit在5.7版本中默认为200，而在8.0版本中默认为10。当IN列表的长度超出该阈值时，优化器会跳过逐个精确探测，转而依靠统计信息进行粗略估算——这种估算往往导致误判，认为全表扫描成本更低，最终出现令人困扰的type=all执行计划。
从根本上说，这并非bug，而是一种设计上的取舍：避免小型查询被大量index dive操作拖慢，但代价是当IN列表较大时很可能丢失索引优化。值得注意的是，该参数仅影响IN、=、BETWEEN等值匹配与范围条件的索引选择，对于LIKE 'abc%'这类前缀模糊查询并无作用。此外，修改参数后仅对新执行的查询语句生效，已缓存的执行计划不会自动刷新。升级到MySQL 8.0后需要格外留意——默认值从5.7的200骤降至10，使得索引退化更容易被触发。
- 该参数仅作用于
IN、=、BETWEEN等值匹配与范围查询的索引选择，对LIKE 'abc%'这类前缀匹配扫描不产生任何影响 - 参数调整后只对新提交的查询语句有效，已缓存的执行计划需手动清除或等待自动失效
- MySQL 8.0中默认值更为激进（仅为10），相比5.7版本（200）更容易触发索引退化，升级后务必重点关注
怎么安全地调整eq_range_index_dive_limit
直接使用SET GLOBAL全局修改风险较高，建议按需进行局部调整。最安全的做法是通过会话级临时调高：执行SET SESSION eq_range_index_dive_limit = 500;，然后运行包含IN子句的查询，观察执行计划的变化。需要注意的是，不要盲目设置过大的值（比如10000），否则单次查询可能因index dive成本过高而卡住，特别是当IN值对应的索引碎片较为严重时——索引下潜的开销会急剧上升。同时，配合ANALYZE TABLE更新统计信息也很关键，如果统计信息过期失真，即使调高了该参数也无济于事。查询当前会话值可使用SELECT @@session.eq_range_index_dive_limit;。
- 推荐使用会话级临时调高方式：执行
SET SESSION eq_range_index_dive_limit = 500;，然后重新运行IN查询验证效果 - 切勿盲目设置过大值（例如10000），否则单次查询可能因index dive开销过高而阻塞，尤其当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字段预估行数合理；参数调整只是辅助手段，数据类型匹配、数据分布特征以及索引结构设计才是真正的根基。
