oracle jdbc 处理大量 in 子句性能骤降的根本原因是 sql 解析与执行计划生成瓶颈，需通过临时表 join、分批（500~800 个值）或 exists 改写替代 in，并确保索引、排序与生命周期管理到位。
oracle jdbc 处理大量 in 子句时性能骤降，不是参数没设对，而是 sql 解析和执行计划本身卡住了——必须绕开 in 常量列表的硬解析瓶颈。
为什么 PreparedStatement 传 5000 个 ? 还是慢？
Oracle 对 IN (? , ? , ...) 的解析不是“逐个绑定”，而是先展开整个参数列表再生成执行计划。一旦值超过 1000，优化器大概率放弃索引选择，退化为全表扫描；即使有索引，也常因统计信息不准或谓词无法下推而失效。
常见现象包括：
- 控制台直接执行
SELECT * FROM orders WHERE id IN (1,2,...,5000)耗时 80ms，但用JdbcTemplate.query()传同样列表却要 3.2s - 执行计划里出现
FULL TABLE SCAN或INDEX FAST FULL SCAN，而非预期的INDEX RANGE SCAN - AWR 报告中
parse time elapsed占比异常高（>40%）
用临时表 + JOIN 替代 IN，但主键和事务不能漏
这是 Oracle 下最稳定、可复现的提速方案，关键不在“建表”，而在“怎么建、怎么用、怎么清”。
- MySQL 下建临时表：必须显式加主键，
CREATE TEMPORARY TABLE t_ids (id NUMBER PRIMARY KEY)，否则JOIN无索引可用 - Oracle 下建全局临时表（GTT）：
CREATE GLOBAL TEMPORARY TABLE t_ids (id NUMBER) ON COMMIT DELETE ROWS，且每次写入后必须COMMIT，否则后续查询查不到数据 - 批量插入时加 hint：
INSERT /*+ APPEND */ INTO t_ids SELECT * FROM TABLE(CAST(? AS number_table))，避免高并发争抢 buffer cache - 应用层别用循环发 N 条
INSERT，改用addBatch()+executeBatch()，单次插入 1000~2000 行为宜
分批查询不是“选做”，是 Oracle 的强制要求
ORA-01795 不是警告，是硬性限制。哪怕你用 MyBatis 动态拼 SQL，超 1000 就报错。分批不是妥协，是唯一能走索引的路径。
- 按主键升序排序后再切片，避免某一批数据集中在热点块上（如 ID 分布不均时）
- 每批控制在 500~800 个值，留出余量防中间件或驱动升级后限制收紧
- 用
UNION ALL拼接结果时，所有子查询字段顺序、类型、别名必须严格一致，否则 MySQL/Oracle 都可能触发隐式转换或临时表 - 别在 for 循环里反复调用
jdbcTemplate.query()：连接池耗尽、事务隔离级别干扰、网络往返叠加，总耗时可能翻 5 倍以上
EXISTS 比 IN 更可靠，但得配对索引
当 IN 子查询来自另一张表（如 WHERE order_id IN (SELECT id FROM temp_orders)），优先改写为 EXISTS。Oracle 的 semi-join 优化器对 EXISTS 更友好，尤其在子查询结果集大时。
- 改写示例：
WHERE EXISTS (SELECT 1 FROM temp_orders t WHERE t.id = o.order_id) - 必须确保
temp_orders.id有索引（主键或唯一约束即可），否则EXISTS会退化为嵌套循环 - 避免在子查询里写
GROUP BY、LIMIT或复杂表达式，否则 Oracle 8.0+ 的 semi-join 优化会被禁用 - 如果子查询字段含
NULL，NOT IN会返回空结果，此时NOT EXISTS是唯一安全替代
真正容易被忽略的点：临时表的生命周期管理、分批时的排序一致性、以及 EXISTS 子查询中索引是否真实生效——这些不写进日志，也不报错，但会让优化效果归零。
