in 语句超 1000 值必分批，oracle 报错、mysql 性能骤降；应按主键排序切片，每批 500–800 值，用 union all 或临时表 join 替代，应用层控制分批并做好状态管理。
IN 语句超 1000 个值就变慢？别硬扛，分批是底线
Oracle 里 IN 列表超过 1000 项直接报错 ORA-01795: maximum number of expressions in a list is 1000；MySQL 虽不报错，但解析慢、执行计划失效、容易触发全表扫描。这不是配置能调出来的，是 SQL 引擎本身的解析瓶颈。
分批是唯一稳妥的兜底方案——不是“可以考虑”，而是“必须做”。关键不在怎么切，而在切完怎么不丢数据、不重复、不拖垮连接池。
- 按主键或唯一字段排序后切片，避免因数据倾斜导致某一批特别大
- 每批控制在 500–800 个值（留余量，防后续加字段或中间件改限制）
- 用
UNION ALL拼接结果时，确保所有子查询字段顺序、类型一致，否则 MySQL 会隐式转换拖慢速度 - 别在应用层用 for 循环发 N 条 SQL：连接开销、事务隔离、网络延迟叠加后，总耗时可能比单条大几百倍
临时表 JOIN 比 IN 快，但建表和清理不能偷懒
把大批量 ID 写入临时表再 JOIN，绕过 IN 解析限制，还能走索引。但临时表不是“一建了之”——MySQL 的 CREATE TEMPORARY TABLE 只对当前连接可见，而 Oracle 的 GLOBAL TEMPORARY TABLE 需提前建好结构，且默认 ON COMMIT DELETE ROWS，不手动 COMMIT 就查不到数据。
- MySQL 下优先用
CREATE TEMPORARY TABLE t_ids (id BIGINT PRIMARY KEY)，显式建主键，否则 JOIN 时没索引，比 IN 还慢 - Oracle 下如果用
INSERT /*+ APPEND */批量写入，记得加/*+ APPEND */提示，否则高并发写临时表会争抢 buffer cache - 应用层必须保证临时表写完立刻
COMMIT（Oracle）或关闭连接（MySQL），否则下次请求可能读到残留数据 - 别用
DROP TEMPORARY TABLE显式删——MySQL 会自动清，Oracle 临时表根本不能 DROP
WHERE id IN (…) 和 WHERE id IN (SELECT id FROM temp) 性能差在哪
表面都是“IN”，底层执行计划天差地别。IN 常量列表会被优化器当作离散值处理，无法走范围索引；而 IN (SELECT ……) 如果子查询有索引、行数可控，优化器可能转成 HASH JOIN 或 SEMI JOIN，效率翻倍。
- MySQL 8.0+ 对
IN (SELECT ……)有 semi-join 优化，但前提是子查询不能含GROUP BY或LIMIT，否则退化成嵌套循环 - PostgreSQL 里
IN (VALUES (……), (……))是更轻量的替代方案，比建临时表快，但只适合单列、无索引需求场景 - SQL Server 的
TABLE VALUE CONSTRUCTOR（即VALUES (1),(2),(3)）配合JOIN，性能接近临时表，且无需 DDL 权限 - 别在子查询里写
SELECT DISTINCT id FROM huge_table——去重本身就会扫全表，反而成瓶颈
分批逻辑放在应用层还是数据库里
分批动作必须由应用层控制。数据库存储过程或函数里做循环分批，等于把应用逻辑锁死在 DB，难测试、难监控、升级时易出错。而且多数数据库不支持动态拼 IN 列表长度，硬写循环反而更慢。
- Java 用
Lists.partition(list, 500)（Guava）或Stream.iterate切片，避免手写 for + subList 边界错误 - Python 用
[ids[i:i+500] for i in range(0, len(ids), 500)]，注意不要用range(0, len(ids), 500)配合list[i]——索引越界风险高 - Node.js 用
Array.prototype.slice，别用splice原地修改，影响原始数组引用 - 切片后统一用 PreparedStatement 绑定参数，别拼字符串——SQL 注入只是其次，关键是不同批次参数类型不一致会导致缓存失效
临时表方案看着省事，但建表权限、清理时机、跨事务可见性全是坑；分批看似多写几行代码，实则可控、可测、可监控。真正卡住性能的，往往不是那 2000 个 ID，而是没意识到分批必须带状态管理——比如哪批失败了、重试时要不要跳过已成功批次。
