MySQL IN子句参数超200个会触发优化器放弃索引走全表扫描，主因是eq_range_index_dive_limit默认值为200，超限后改用粗略统计估算成本，易误判执行计划；应改用分批查询（≤150/批）或临时表JOIN替代。
IN子句里塞几百个常量值，MySQL大概率会放弃索引走全表扫描——这不是配置问题，是优化器基于成本估算的主动放弃。
为什么IN列表一多就丢索引？
MySQL对IN的range访问有硬性阈值：默认eq_range_index_dive_limit=200。超过这个数，优化器不再逐个下探索引树（index dive），改用粗略统计（index statistics）估算成本，结果往往判定“全表扫比回表N次更便宜”，于是type变成ALL或index，key为空。
- 用
EXPLAIN确认：如果type是ALL或index，且key为NULL，基本就是被放弃了 - 即使字段有索引、类型完全匹配，只要值数量≥200，就可能触发该机制
- MySQL 8.0+虽有改进，但5.7及多数生产环境仍卡在保守策略上
IN值太多时，怎么让索引重新生效？
不靠调参，靠改写。核心思路是把“大IN”变成优化器愿意处理的形态：
- 拆成多个小
IN查询，每批≤150项，用UNION ALL拼接（避免UNION去重开销） - 把常量列表写入临时表，建索引，再
JOIN：CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY);<br>INSERT INTO tmp_ids VALUES (1),(2),...;<br>SELECT t.* FROM your_table t JOIN tmp_ids ON t.id = tmp_ids.id;
- 如果业务允许，改用
EXISTS配合临时表（尤其当主表很大、匹配行少时）
哪些操作会让IN彻底失效，哪怕只写3个值？
索引命中的前提不是“写了索引”，而是“没破坏索引可用性”。常见自毁行为：
- 类型不匹配：
user_id是BIGINT，却写IN ('1','2','3')→ 触发隐式转换，索引失效 - 字段套函数：
WHERE UPPER(name) IN ('A','B')→ 索引无法用于前缀匹配 - 复合索引错位：
INDEX (a,b,c)，写WHERE a IN (1,2) AND c = 3→ 只能用到a，c跳过b导致索引截断 - 子查询含
NULL：WHERE id IN (SELECT user_id FROM orders)若子查询返回NULL，整个条件逻辑变复杂，优化器倾向退化
调eq_range_index_dive_limit有用吗？
理论上可以，但实际慎用：
- 设太高（如
1000）会导致每次EXPLAIN都扫索引树，高并发下CPU和IO压力陡增 - 设太低（如
50）会让原本能走索引的小IN也被误判 - 它只影响成本估算方式，不改变底层执行逻辑；不如直接拆分或换
JOIN来得确定 - 线上环境建议保持默认，把精力放在SQL改写上
真正卡住性能的往往不是IN本身，而是把它当成万能胶——值一多就堆，类型一混就不管，索引一建就以为万事大吉。拆、转、验，三步缺一不可。
