IN子句传几百上千个值时，查询变慢甚至结果错乱，不是你写法有问题，而是数据库优化器主动“放弃精确评估”了——它不再逐个探测索引，转而靠统计信息瞎猜。我们先做一个快速背景回顾。
MySQL中IN超过200个值为什么执行计划突然崩坏？
是什么导致了这种“崩坏”？根源其实在于MySQL优化器的一个默认阈值。MySQL 5.7/8.0 默认eq_range_index_dive_limit = 200。这个参数决定了优化器在执行范围查询时，是否对每个值进行精确的成本评估。一旦IN列表长度超过200，优化器就跳过 index dive（也就是索引深度探测），改用统计信息粗略估算。结果呢？往往选错索引，甚至直接触发全表扫描。
怎么确认自己是否踩了坑？可以查看当前阈值：SHOW VARIABLES LIKE 'eq_range_index_dive_limit';。更关键的，用EXPLAIN FORMAT=JSON分析执行计划，盯着"range_analysis"段里有没有出现"index_dives_for_eq_ranges": false——有的话，说明优化器已经“偷懒”了。
那能不能调高这个阈值？通常不推荐。调高阈值只是让优化器“更努力”地做精确探测，但无法解决解析开销过大和max_allowed_packet超限的问题。治标不治本。
用临时表 + JOIN 替代大列表IN的实操要点
把ID列表从SQL字符串里摘出来，存入临时表再关联查询，是目前最稳定、最通用的解法。具体操作分三步走：
- 建临时表：推荐使用
Memory引擎并设置主键。示例：CREATE TEMPORARY TABLE tmp_ids (id BIGINT NOT NULL PRIMARY KEY) ENGINE=Memory; - 批量插入数据：避免逐条插入，用批量插入语句。例如
INSERT INTO tmp_ids VALUES (1),(2),(3),...,(1000); - 用JOIN替代IN：核心是关联查询，必须用
JOIN，而不是IN (SELECT ...)。正确的写法是SELECT t.* FROM target_table t JOIN tmp_ids i ON t.id = i.id;
注意一个常见误区：如果用 IN (SELECT id FROM tmp_ids)，就又退回到子查询模式，MySQL可能物化失败，或者退化成效率低下的嵌套循环执行。效果大打折扣。
无法建临时表时，分批查询怎么避坑？
如果环境受限——比如是只读库、没有DDL权限，或者ID来自不可信的前端输入——临时表方案就不可行了。这时，分批查询是唯一安全的选择。
- 控制单批大小：建议单批控制在500～1000个值以内，这样既能避开
eq_range_index_dive_limit触发降级，又不会突破max_allowed_packet限制。 - 应用层循环合并：在应用层循环发起多个
IN查询，然后合并结果（Ja va 用Stream.concat，Python 用itertools.chain）。 - 慎用
UNION ALL：不要试图用UNION ALL在SQL层面拼接多个查询——语句过长，依然会触发Packets larger than max_allowed_packet are not allowed的错误。 - 排序与分页统一处理：如果查询包含
ORDER BY和LIMIT，必须在应用层统一排序和分页。否则各批次结果交叉，逻辑完全错乱。
IN子查询 vs EXISTS：什么情况下必须换？
当IN的右边是一个子查询，且子查询需要关联外层字段时，情况就变了。比如这样的查询：WHERE id IN (SELECT user_id FROM logs WHERE logs.time > orders.created_at)——这在MySQL中是无法执行的，语法直接报错。必须改写为EXISTS的形式。
除了语法限制，还有两个重要的性能差异需要留意：
IN子查询返回NULL会导致整行被排除，而EXISTS不受NULL影响，逻辑更稳定。- 在MySQL 5.7以前，
IN子查询经常退化为嵌套循环执行；而EXISTS配合合适的索引，通常快一个数量级。
所以对于大数据量的子查询场景，优先测试EXISTS的执行计划，不要默认沿用IN。
真正容易被忽略的点是：空列表、NULL值、类型混用这三类问题不会报错，但结果完全不对。比如传空数组给IN ()，MySQL直接报语法错误，而PostgreSQL会静默返回空集；又比如IN (1, '2')这种混合类型，在多数数据库引擎中会触发隐式类型转换，导致索引失效。这些问题必须在应用层提前校验，不能指望数据库来兜底。
