我正在寻找一种策略来批处理我的所有查询（使用IN子句）来克服IN子句（See here）上数据库的限制。
我通常会得到大小为100000到305000的列表。因此，解决这个问题非常重要。
到目前为止，我已尝试过两种策略。
策略1：
创建一个实体，因此创建一个包含一列的表来保存这些值（我们可以在JPA 2.0供应商独立的情况下动态创建临时表吗？）并使用临时表中的数据作为子查询最终清理临时表之前的原始查询。
优势：非常高效的查询。真的很快，我必须承认我提到过的数字，大概不到一分钟。
可能的缺点：到目前为止，临时表的使用实际上是永久性的。
策略2：
计算给定输入列表的批量大小，并为每个批次执行查询并累积结果。
优点：没有临时表。易于同一交易中的任何线程。
缺点：一个很大的缺点是执行所有批次所需的时间。对于上述数字，目前处于不可接受的水平。在5到15分钟之间完成任务！
我将非常感谢所有JPA专家的反馈，建议或改进。
感谢。
答案 0 :(得分：1)
我只测试了多达50,000个整数但我在使用各种方法拆分大型列表方面有一些相当不错的性能数据，CLR和数字表在高端领先包装：
不确定您是使用整数还是字符串，但结果应大致相同。
顺便说一句，我会承认我不知道JPA 2.0是什么，但我认为你可以控制它发送给SQL Server的列表的格式。