mysql对长in列表弃用索引走全表扫描，是因range_optimizer阶段成本预估超阈值（默认100）且索引未全覆盖，属主动策略而非bug；需确保索引有效、类型一致、必要时调参。
IN 列表太长时，MySQL 为什么突然走全表扫描？
因为优化器在 range_optimizer 阶段对 IN 常数列表做了成本预估，当列表长度超过阈值（默认 100），且没有可用索引覆盖全部值时，它会放弃 range 计划，回退到全表扫描——不是 bug，是成本模型主动“弃疗”。
-
IN列表元素数 >range_optimizer_max_matches（默认 100）时，优化器直接跳过 range 计划生成 - 即使有索引，若
IN中存在NULL或类型不一致（如字符串混数字），会导致索引失效，range 计划被排除 - 每个
IN值都会触发一次等值查找评估，但优化器不会真的执行 100 次索引定位，而是用统计信息估算总成本
如何让 IN (a,b,c...) 走上索引 range 扫描？
核心是让优化器相信：走索引比全扫便宜，且能准确估算行数。这依赖三件事：索引结构、值的确定性、配置干预。
- 确保列上有单列索引或复合索引的最左前缀，例如查询
WHERE status IN ('active','pending')，status必须是索引首列 - 避免隐式类型转换：
WHERE id IN ('1','2','3')对INT列会强制转类型，索引失效；统一用1,2,3 - 必要时调低
range_optimizer_max_matches（会话级）：SET SESSION range_optimizer_max_matches = 200，但需配合EXPLAIN验证是否真生成 range 计划
EXPLAIN 看到 type=range 却实际很慢？检查这几个点
type=range 只代表用了索引范围扫描，不代表高效。真正瓶颈常在“扫了多少索引行”和“回表代价”。
- 看
rows字段：如果远大于实际匹配数（比如rows=50000但只返回 10 行），说明统计信息不准，ANALYZE TABLE可能有帮助 - 看
key_len：若比预期小（如索引有 3 列，但key_len只显示第一列长度），说明只有部分索引生效，IN后值可能触发了索引截断 - 若
Extra出现Using where; Using index是理想状态；若只有Using where，说明没覆盖索引，要回表查数据，IN值越多，回表越频繁
替代 IN 的几种写法，什么情况下更靠谱？
不是所有 IN 都该硬扛。当常量列表动态生成、数量不可控时，得换思路。
- 值数少（≤10）、稳定：坚持用
IN，最简洁，优化器处理成熟 - 值数多（≥200）、来自外部输入：改用临时表 +
JOIN，例如CREATE TEMPORARY TABLE tmp_ids(id INT PRIMARY KEY); INSERT ...; SELECT * FROM t JOIN tmp_ids ON t.id = tmp_ids.id - 需要去重或带权重：别拼
IN，用VALUES ROW()+JOIN（MySQL 8.0.19+）或UNION ALL子查询，可控性更强
MySQL 的 range_optimizer 对 IN 的处理，本质是拿统计信息赌“值分布”，而真实数据往往不按套路出牌。最易忽略的是：你以为在优化 SQL，其实是在和优化器的估算偏差博弈。
