MySQL对大量IN参数处理会机制性失效，非单纯变慢：超1000个值时优化器改用估算致执行计划错误，超10000个易触max_allowed_packet限制；推荐临时表+JOIN方案，注意批量插入与索引优化。
直接用 IN 传几千甚至上万个参数，MySQL 不是“慢一点”，而是执行计划崩、解析卡死、甚至报 Packets too large 错误。这不是索引没建好，是 MySQL 解析器和优化器根本扛不住这个量级的硬编码列表。
为什么 IN 参数一多就崩：不是慢，是机制失效
MySQL 对 IN 列表的处理不是线性扫描，而是随参数量跳变式退化：
-
IN后少于 100 个值：优化器走range或ref，基本无感 - 100–1000 个值：开始排序去重 + 二分查找，依赖索引质量，偶尔抖动
- 1000+ 个值：
eq_range_index_dive_limit（默认 200）触发，优化器放弃精确 index dive，改用统计估算 → 执行计划大概率选错，比如该走索引却全表扫 - 10000+ 个值：SQL 文本长度极易超
max_allowed_packet（默认 4MB），直接报错；即使不超，解析耗时也占查询总耗时 70% 以上
临时表 + JOIN 是最稳的通用解法
把应用层传来的 ID 列表转成数据库内的一张临时表，再用 JOIN 查，绕过 SQL 解析瓶颈，还能建索引、复用执行计划。
- 建表用
ENGINE=Memory，主键设为HASH索引（PRIMARY KEY USING HASH），单值查找是 O(1) - 插入必须批量，别用循环单条
INSERT；JDBC 推荐每 1000 行executeBatch()，MyBatis 用<foreach>的batch="true" -
JOIN时别写成SELECT *，尤其当临时表字段名和主表冲突（如都叫id），必须加表别名或显式列名 - 临时表生命周期绑定会话，不用手动
DROP，但注意连接池复用下可能残留，建议每次用前加DROP TEMPORARY TABLE IF EXISTS temp_ids
分批查询只适合低并发、结果集小的场景
拆成多个 IN (1,2,...,999) 查询，看似简单，实际暗坑不少：
- 每批一次网络往返，10 批就是 10 次 round-trip，延迟叠加明显；高并发下连接数、CPU 调度压力翻倍
- MySQL 连接池容易被占满，尤其用 HikariCP 默认配置时，
connection-timeout可能先于 SQL 执行完就超时 - 结果合并逻辑在应用层写错很常见：比如漏掉某批空结果、去重逻辑没对齐（
IN天然去重，分批后addAll可能重复） - 真正安全的上限不是“数据库允许多少”，而是你业务能容忍的最大单次响应时间 —— 建议实测 500 或 999 批大小下的 P99 延迟，再决定
EXISTS 和子查询改写只解决特定语义
如果原逻辑只是“判断是否存在”，比如 WHERE id IN (SELECT user_id FROM log WHERE type = 'pay')，那 EXISTS 是更轻量的选择：
- 必须带关联条件：
EXISTS (SELECT 1 FROM log l WHERE l.user_id = u.id AND l.type = 'pay')，否则退化成全表扫描 - 子查询里
SELECT 1和SELECT *没区别，但别写SELECT *，字段膨胀可能干扰 semi-join 优化 -
IN遇到子查询返回NULL时整个条件为UNKNOWN，而EXISTS不受NULL影响，语义更干净 - 但若你需要取子查询里的其他字段（比如订单金额、时间），或者后续要
GROUP BY，EXISTS就无能为力，只能回到JOIN或临时表
临时表方案看着步骤多，但它把“参数传输”从 SQL 字符串里彻底剥离，让数据库回归集合运算本质。最容易被忽略的是：批量插入的性能占比常超 60%，而很多人卡在建表或 JOIN 写法上，反而没调优插入这一环。
