当IN列表超过几百个值时性能急剧下降，应改用临时表+JOIN方案：建带主键的临时表、批量插入、INNER JOIN替代IN、确保目标字段有索引。
直接结论：当 IN 列表超过几百个值，尤其是应用层传入 1000+ 个 ID 时，硬拼 WHERE id IN (1,2,3,...) 几乎必然变慢——不是语法错，而是 MySQL 底层执行逻辑和资源限制决定的。用临时表 + JOIN 是最稳、最可控、线上验证过千次的解法。
为什么硬拼大 IN 列表会慢到不可接受
这不是“写法不优雅”的问题，是 MySQL 内部机制卡住的硬伤：
-
eq_range_index_dive_limit默认为 200：IN 值数量 ≥ 200 时，优化器放弃扫描索引树（index dive），改用粗略的索引统计（index statistics）估算成本 → 极易选错执行计划，比如该走索引却全表扫 - SQL 解析开销陡增：10000 个整数拼成字符串，MySQL 要 tokenize、去重、排序、构建二分查找数组，这部分 CPU 消耗随长度非线性增长
- 网络与参数绑定压力：JDBC/MyBatis 批量传参时，超长
IN易触发max_allowed_packet截断，或引发 PreparedStatement 编译失败 - 查询缓存失效（旧版）、执行计划无法复用：每个不同长度/值组合都算新 SQL，Plan Cache 彻底失效
临时表 + JOIN 的标准操作流程
别跳步，四步缺一不可：
- 创建临时表，显式指定主键或唯一索引：
CREATE TEMPORARY TABLE temp_ids (id BIGINT PRIMARY KEY);
（用BIGINT防隐式转换；PRIMARY KEY自带索引，比INDEX更可靠） - 批量插入数据（非逐条）：
INSERT INTO temp_ids (id) VALUES (1),(2),(3),...,(10000);
（单条 INSERT 多值，每批 ≤ 1000 行；避免 10000 条单 INSERT） - 用
INNER JOIN替代IN，且把过滤条件尽量下推到ON子句：SELECT u.* FROM users u INNER JOIN temp_ids t ON u.id = t.id WHERE u.status = 'active';
（不是WHERE u.id IN (...) AND u.status = 'active'） - 确认目标字段有索引：
SHOW INDEX FROM users看id是否在索引列中；若常加status过滤，优先建复合索引(id, status)或(status, id)（按区分度选顺序）
容易被忽略的三个坑
很多团队照着做还是翻车，问题就出在这几个细节：
- 临时表没加
PRIMARY KEY或UNIQUE：MySQL 可能对temp_ids.id不走索引，EXPLAIN里key显示NULL—— 必须加 - JOIN 后字段名冲突没处理：比如
users.id和temp_ids.id同名，SELECT *会报错或结果错乱 → 显式写SELECT u.*，别偷懒 - 临时表生命周期管理不当：连接未关闭前临时表一直存在，但若应用用了连接池，下次获取的连接可能残留旧临时表 → 每次使用前加
DROP TEMPORARY TABLE IF EXISTS temp_ids;，或用唯一命名如temp_ids_20260510_12345
真正难的不是写那几行 SQL，是判断什么时候该切——比如一个接口要查 5000 个订单，你得在代码里埋个阈值判断：超过 300 就走临时表，否则直拼 IN。这个边界值，得看你的 eq_range_index_dive_limit 设置和实际压测结果，不是拍脑袋定的。
