Oracle的1000项是真·语法限制，报ORA-01795；SQL Server约2100项受参数绑定机制限制；MySQL无IN项数硬限，但受max_allowed_packet、优化器退化等隐性约束。
不是所有数据库都因“参数过多”报错，而是不同系统有各自的硬性限制或隐式瓶颈——直接拼 WHERE id IN (1,2,...,1001) 在 Oracle 会触发 ORA-01795，在 SQL Server 约 2100 项后失败，MySQL 则通常不拦语法，但可能卡在 max_allowed_packet 或优化器放弃索引。
Oracle 的 1000 项是真·语法限制
Oracle 解析器明确拒绝超过 1000 个表达式的 IN 列表，错误信息固定为 ORA-01795: maximum number of expressions in a list is 1000。这不是性能警告，是解析阶段直接报错，SQL 根本不会进优化器。
- 即使你用绑定变量（
:id1, :id2, ...），只要变量个数超 1000，同样失败 -
IN (SELECT ...)不受此限，因为子查询返回的是结果集，不是“表达式列表” - 某些 JDBC 驱动会提前拦截并抛出类似错误，但根源仍是 Oracle 内核限制
SQL Server 的 ~2100 项源于参数绑定机制
SQL Server 对单条语句的参数总数有限制（约 2100 个），IN 中每个值若用参数占位（@p1, @p2, ...），就会快速触顶。错误常表现为 SQL Server error 8623 或连接中断。
- 拼字符串绕过参数（如
IN ('a','b',...)）可避开此限，但引入 SQL 注入和计划缓存爆炸风险 -
EXISTS+ 临时表或表值参数（TVF）是更安全的替代路径 - 使用
STRING_SPLIT（SQL Server 2016+）需注意其返回无序、无索引，JOIN 性能未必优于分批IN
MySQL 没有 IN 项数限制，但有三重隐形墙
MySQL 官方从未设 IN 元素数量上限。所谓“1000 限制”是开发者从 Oracle 迁移时的误传。真正卡住你的通常是：
-
max_allowed_packet：整个 SQL 字符串超限（默认 4MB），拼 10 万个 ID 很容易突破 - 优化器退化：当
IN值过多（尤其 >5000），MySQL 可能放弃走索引，改用全表扫描 - 客户端驱动限制：例如某些版本 MyBatis 或 Hibernate 会在 Java 层主动截断，抛
SQLException而非让 SQL 到达 MySQL
为什么不用 IN 改用 JOIN 却能绕开？
本质是把“数据库解析大量字面量”的压力，转成“构建一张小表 + 索引 + 哈希/排序连接”的可控流程。临时表有主键或索引后，JOIN 可复用执行计划，且不放大网络包体积。
- 临时表必须显式加
PRIMARY KEY或INDEX，否则JOIN可能比IN更慢 - 用
CREATE TEMPORARY TABLE比INSERT ... SELECT更轻量，避免锁维表 - 别依赖“会话结束自动删”，存储过程中应显式
DROP TEMPORARY TABLE，防止连接池复用时残留
真正危险的不是“超 1000”，而是没区分清楚：哪一层在报错（数据库内核 / 驱动 / ORM）、错误是语法拒绝还是性能熔断、以及替代方案是否引入新瓶颈（比如临时表没索引反而更慢）。
