Oracle IN子句超1000报ORA-01795，需Java层切分List为每批≤1000项后循环查询，或建ON COMMIT DELETE ROWS临时表JOIN替代。
Oracle IN子句超1000报错 ORA-01795 怎么办
mybatis 执行带 in 的 sql 时，如果传入的 list 超过 1000 个元素，oracle 直接拒绝执行，抛出 ora-01795: maximum number of expressions in a list is 1000。这不是 mybatis 的 bug，是 oracle 硬性限制，绕不开，只能拆或换策略。
常见错误现象：本地测试几百条数据没问题，上线后查批量订单、日志、ID 列表就突然失败，堆栈里只看到 ORA-01795，没其他线索。
- 别在 SQL 里硬拼超长
IN—— MyBatis 的<foreach>会原样展开，到 Oracle 那一步就跪了 - 别依赖数据库驱动自动拆分 —— JDBC 和 Oracle 都不干这事，MyBatis 也不处理这个边界
- 临时改
in为= ANY(ARRAY[...])不行 —— Oracle 不支持这种语法，会报ORA-00920
用 MyBatis 动态切分 List，手写循环执行
最直接、零额外依赖的解法：Java 层把大 List 拆成每组 ≤ 1000 个元素的子列表，再逐批查。适合读多写少、结果集不要求强一致的场景（比如后台导出、统计）。
关键点不是“怎么切”，而是“怎么让 MyBatis 复用同一段 SQL”——避免写 N 个 mapper 方法。
- 在 service 层用
Lists.partition(list, 1000)（Guava）或手动 for 循环切分 - mapper 接口保持单参数：
List<String> ids，SQL 里仍用标准<foreach>，不用改 - 每次调用
mapper.selectByIds(subList)，结果用new ArrayList<>()合并 - 注意事务和连接复用：批量查不涉及写操作，一般无需开启新事务；但若查完立刻更新，得确保所有批次在同一个事务内
性能影响：N 次 round-trip，网络开销线性增长；但比建临时表轻量，无 DDL 权限要求。
用 Oracle 临时表 + JOIN 替代 IN
当数据量极大（几万+）、且需要和其他大表关联过滤时，切分执行太慢，该上临时表。本质是把“条件列表”变成“物理表”，让 Oracle 优化器走 hash join 或 nested loop。
必须用 ON COMMIT DELETE ROWS 的全局临时表（GLOBAL TEMPORARY TABLE），否则并发下数据串扰。
- 提前建好临时表：
CREATE GLOBAL TEMPORARY TABLE tmp_ids (id VARCHAR2(50)) ON COMMIT DELETE ROWS - Java 中分批
INSERT INTO tmp_ids（同样 ≤ 1000 条/批），用batchInsert提升效率 - 主查询改写为
SELECT ... FROM real_table r JOIN tmp_ids t ON r.id = t.id，MyBatis 里直接写死这个 JOIN - 临时表不需要清空 —— 事务结束自动清，但要注意 session 级别复用时别漏 commit
兼容性注意：Oracle 10g+ 都支持；MySQL / PostgreSQL 没这限制，此方案仅限 Oracle 环境。
MyBatis XML 里写动态 SQL 拆分？别试
有人想在 <select> 标签里用 <if> 或脚本逻辑判断 size 后自动分页执行 —— MyBatis 不支持运行时控制执行次数，XML 是静态解析的，做不到。
常见误操作：
- 用
<bind>算出子列表再<foreach>—— 只能生成一段 SQL，还是超限 - 嵌套
<foreach>模拟分组 —— 语法不合法，XML 解析直接失败 - 指望
databaseId切换方言来规避 —— Oracle 方言里照样有 1000 限制，不是方言问题
真正要动态执行，逻辑必须落在 Java 层。XML 只负责“单次查询怎么写”，不负责“查几次”。
最容易被忽略的是临时表的权限和生命周期管理：DBA 可能只给 SELECT 权限，忘了给 INSERT；或者用了 ON COMMIT PRESERVE ROWS 导致下次请求读到残留数据。切分方案则容易漏掉异常时的中断处理 —— 某一批失败，后续批次是否还要继续？这些细节不处理，线上就是偶发故障。
