根本原因是eq_range_index_dive_limit默认200，超限后优化器弃用精确的index dive而改用粗略统计，误判成本致全表扫描；稳定方案为分批查（≤200/批）、临时表join、exists改写。
为什么IN参数一多，MySQL 5.7就放弃走索引？
根本原因是优化器在预估成本时触发了 eq_range_index_dive_limit 阈值。MySQL 5.7 默认值是 200，当 IN 列表中值的数量超过这个数，优化器就不再逐个下潜二级索引去精确统计每个值对应的数据行数（即不做 index dive），而是改用粗略的统计信息估算——估算误差大，常导致它误判“走索引比全表扫描还贵”，于是直接选 type: ALL。
这不是“索引坏了”，而是优化器主动绕开了它；即使 EXPLAIN 显示 possible_keys 有索引，key 字段也常为 NULL。
调低 eq_range_index_dive_limit 要谨慎
临时设成 10 或 50 确实可能让小批量 IN（比如 300 个 ID）重新走索引，但副作用明显：
- 每次查询前都要做更多次索引页访问（index dive），单次查询延迟上升，IOPS 暴涨
- 高并发下容易打满 IO，引发雪崩
- 该变量是会话级或全局级的，改了会影响所有查询，不是定向修复
所以不推荐把它当作常规优化手段，仅限诊断或极低频、强一致要求的离线任务临时使用。
真正稳定有效的三种落地方式
优先级从高到低：
-
分批查：把 5000 个 ID 拆成每批 ≤ 200 个（严格低于
eq_range_index_dive_limit），用循环或应用层并发执行。注意控制连接复用和事务粒度，避免短连接风暴 -
用临时表 + JOIN：先
CREATE TEMPORARY TABLE tmp_ids (id INT PRIMARY KEY)，批量INSERT所有 ID，再JOIN主表。MySQL 5.7 对临时表统计信息更友好，且能走主键索引，执行计划稳定为type: eq_ref或ref -
改写为 EXISTS：如果原逻辑是
WHERE id IN (SELECT id FROM t2 WHERE ...)，换成WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.id AND ...)。EXISTS 是半连接，优化器通常保留外层索引，且不因子查询结果集大小退化
最容易被忽略的细节
分批处理时，很多人只拆 ID，却忘了 ORDER BY 和 LIMIT 的语义一致性——比如原查询带 LIMIT 10，分 5 批查，每批都 LIMIT 10，最后合并再取前 10，才等价；直接拼 UNION ALL 再 LIMIT 会出错。另外，临时表方案必须确保客户端有 CREATE TEMPORARY TABLES 权限，且不能跨会话复用，应用重启后需重建。
