mysql中in子句超200值会因eq_range_index_dive_limit阈值触发估算降级，导致索引弃用、执行计划错误；应改用带主键的临时表join或分批查询。
IN 子句传入几百上千个值时，查询变慢不是“写法错”，而是 MySQL / PostgreSQL 等优化器在参数量超过阈值后主动放弃精确评估——你看到的执行计划里“预计扫描13行，实际扫500万行”，就是这个机制在起作用。
为什么 IN 超过 200 个值就开始不可靠
MySQL 5.7 和 8.0 默认 eq_range_index_dive_limit = 200。一旦 IN 列表长度超过该值，优化器不再对每个值做 index dive（索引深度探测），转而依赖统计信息估算，极易选错执行计划。
更隐蔽的问题是：max_allowed_packet 限制 SQL 文本总长度。2000 个整数拼成的字符串可能超限，直接报 Packets larger than max_allowed_packet are not allowed。
- 用
SHOW VARIABLES LIKE 'eq_range_index_dive_limit';查当前阈值 - 用
EXPLAIN FORMAT=JSON看"range_analysis"段是否含"index_dives_for_eq_ranges": false - 别指望调高
eq_range_index_dive_limit解决问题——它只是让优化器更“努力”，但不解决根本瓶颈
临时表 + JOIN 是最稳的通用解法
把大量 ID 从 SQL 字符串里摘出来，存进临时表，再用 JOIN 关联，既绕过解析开销，又能走索引（尤其用 Memory 引擎 + HASH 索引时查找是 O(1)）。
- 建表：
CREATE TEMPORARY TABLE tmp_ids (id BIGINT NOT NULL PRIMARY KEY) ENGINE=Memory; - 批量插入（JDBC 批处理 or MyBatis
<foreach></foreach>）：INSERT INTO tmp_ids VALUES (1),(2),(3),...,(1000); - 关联查询：
SELECT t.* FROM target_table t JOIN tmp_ids i ON t.id = i.id; - 注意：不要用
IN (SELECT id FROM tmp_ids)—— 这又退回子查询模式，优化器可能物化失败
分批查询比硬扛更可控
当无法建临时表（如只读数据库、无 DDL 权限），或 ID 列表来自前端不可信输入时，分批是唯一安全选择。
- 单批控制在 500～1000 个值以内（避开
eq_range_index_dive_limit和网络包大小双重风险） - 应用层做循环，每次发一个
IN查询，结果合并（Java 可用Stream.concat，Python 用itertools.chain） - 别用
UNION ALL在 SQL 层拼接——语句过长照样触发max_allowed_packet错误 - 加
ORDER BY和LIMIT的场景要格外小心：必须在外层统一排序分页，否则各批次结果交叉导致逻辑错误
EXISTS 或 JOIN 替代 IN 子查询时的关键区别
原始写法 WHERE id IN (SELECT id FROM t2 WHERE ...) 是半连接（semi-join），但 MySQL 5.7 默认不启用 semijoin 优化，容易退化成嵌套循环；而显式 JOIN 或 EXISTS 能明确引导优化器走更优路径。
-
EXISTS更适合“存在性判断”，且内表有索引时性能通常优于IN（尤其子查询结果集大） -
JOIN更适合需要取内表字段、或需去重/聚合的场景，但要注意INNER JOIN会过滤外层无匹配的行，语义是否等价需确认 - MySQL 8.0+ 可开启
SET optimizer_switch='semijoin=on';让IN子查询自动转为 semi-join，但不如手动改写可控
真正卡住人的，往往不是“该用哪种方案”，而是没意识到 IN 在千级参数时已脱离“语法正确”范畴，进入优化器策略失效区——此时任何不改变数据落地方式的“SQL 微调”，都只是在修水管漏水时拧紧水龙头。
