MySQL IN子句无1000值硬限制，真正瓶颈是max_allowed_packet、net_buffer_length和eq_range_index_dive_limit（默认200），超限易致解析失败、执行计划退化或报错；推荐用临时表+JOIN或动态分批替代。
IN 子句塞几千甚至上万个值，不是“有点慢”，而是大概率触发硬解析失败、执行计划退化、连接超时或 Packet for query is too large 报错——这不是配置调优能救的，必须换思路。
为什么 IN 参数一多就崩，和 Oracle 的 1000 限制根本不是一回事
MySQL 没有硬编码的“1000 个值”限制，真正卡脖子的是三个系统级参数：max_allowed_packet（默认 4MB）、net_buffer_length（默认 16KB）、以及优化器内部的 eq_range_index_dive_limit（默认 200）。一旦 IN 列表长度 ≥ 200，MySQL 就放弃扫描索引树做精确成本估算，转而用统计值粗估，结果常选错执行计划，比如该走 range 却变成 ALL。
- 拼出来的 SQL 字符串超过
max_allowed_packet？直接报Packet for query is too large，连解析都不让进 - 客户端驱动（如 MySQL Connector/J）在预编译时对长参数列表支持差，可能静默截断或抛
CommunicationsException -
EXPLAIN显示type: ALL或rows高得离谱？八成是优化器被巨量常量搞晕了，索引白建
临时表 + JOIN 是最稳的替代方案，但建表方式决定成败
用 CREATE TEMPORARY TABLE 替代 IN 不是加个表就行，关键在三处：引擎选型、主键/索引、批量插入节奏。
- ID 是整数且 ≤ 5 万：用
ENGINE=MEMORY+PRIMARY KEY，例如CREATE TEMPORARY TABLE tmp_ids (id BIGINT UNSIGNED PRIMARY KEY) ENGINE=MEMORY - ID 超过 5 万、含字符串、或需持久一点：切到
ENGINE=InnoDB，并立刻加主键，CREATE TEMPORARY TABLE tmp_ids (id VARCHAR(32), PRIMARY KEY(id)) ENGINE=InnoDB - 别单条
INSERT：用INSERT INTO tmp_ids VALUES (1),(2),(3),...,(1000)批量插，每批 ≤ 1000 行；插完立刻ANALYZE TABLE tmp_ids（尤其 InnoDB 引擎） - JOIN 写法要显式驱动顺序：
SELECT t.* FROM target_table t INNER JOIN tmp_ids i ON t.id = i.id，确保tmp_ids是驱动表
分批查询看似简单，但容易漏掉边界和合并逻辑
把 10000 个 ID 拆成 10 个 IN (1..1000) 查询，不是加个 for 循环就完事。实际落地要防三类坑：
- 批次大小别死守 1000：根据平均 ID 长度动态算，目标是单条 SQL 总长
< max_allowed_packet * 0.7（留缓冲），比如 UUID 字符串比 INT 占更多字节 - 结果去重不能靠应用层
Set：数据库返回顺序不保证，UNION ALL比UNION快得多，去重交给外层SELECT DISTINCT或业务逻辑 - 带分页或聚合时不能分批查再 merge：比如要取 “IN 列表中前 20 条最新订单”，必须先
SELECT id FROM orders WHERE id IN (...) ORDER BY created_at DESC LIMIT 20—— 分批后排序失效 - 注意事务隔离：如果在事务里分批查，各批次之间数据一致性由隔离级别保障，
READ COMMITTED下可能漏新提交的匹配行
别碰 VALUES ROW() 和子查询，除非你清楚它们的隐性代价
MySQL 8.0.19+ 的 VALUES ROW() 看似优雅：SELECT t.* FROM target_table t WHERE t.id IN (SELECT id FROM (VALUES ROW(1),ROW(2),... ) AS v(id))，但它仍有硬伤：
- VALUES 行数上限约 65535，但实际受
max_allowed_packet更早掐断 - 优化器对
VALUES表的统计信息极弱，JOIN 时仍可能误判驱动顺序 - 子查询写法如
WHERE id IN (SELECT ...)若内层无索引或返回空集，外层可能全表扫——比临时表还难排查 - 所有这些方案都依赖目标字段已有有效索引：
EXPLAIN中key列必须非NULL，type至少是range，否则换啥都白搭
临时表和分批都不是银弹，核心差异在于：临时表适合 ID 集合一次性传入、后续还要复用（比如同一会话里查两次不同字段）；分批适合 ID 来源不可控、且查询逻辑轻量（比如纯主键等值查）。最容易被忽略的是字符集和 collation 匹配——哪怕临时表字段类型和主表完全一致，只要 collation 是 utf8mb4_0900_as_cs 而主表是 utf8mb4_0900_ai_ci，JOIN 就会静默失效。
