Spring Data JPA IN查询参数超过MS SQL上限报错该如何处理？

1、框架执行超出数据库限制的无效SQL是否属于Bug？是否需要开发者自行拆分查询来适配该场景？ #

不属于Bug。Spring Data JPA定位为数据库无关的持久层框架，不同数据库的IN参数上限、全局参数上限差异极大：比如Oracle限制IN子句参数最多1000个，SQL Server不同版本全局参数上限在1000~2100区间浮动，MySQL无明确硬限制仅受报文大小约束。框架不可能内置所有数据库的限制规则，也无权随意修改开发者定义的查询逻辑，因此该场景需要开发者自行适配。

2、加载关联关系时使用IN语句，batch size会生效，自动执行多个分批IN查询，为什么自定义查询场景下该配置不生效？ #

关联加载的batch_size是ORM层（EclipseLink/Hibernate）专门针对实体关联抓取场景设计的内置优化：该场景下实体加载流程完全由ORM框架管控，框架明确知道待加载的关联实体主键集合总量，会自动按照配置的batch size拆分参数执行多次查询。
而自定义IN查询属于业务层自定义逻辑，参数集合由开发者主动传入，ORM框架默认不会对业务传入的参数做自动切割改写，因此该配置不会生效。

3、是否可以批量执行单个查询（例如findByName）来规避参数上限问题？ #

可以但不推荐：循环执行单条件查询会产生N次数据库请求，IO开销过高性能极差。更推荐以下两种方案：

• 参数集合分批切割：将待查询的参数集合按照小于数据库上限的阈值拆分，分批执行查询后合并结果。示例代码如下：

// 按900个一组拆分，低于SQL Server的参数限制
List<List<String>> nameBatches = Lists.partition(names, 900);
List<Course> allCourses = new ArrayList<>();
for (List<String> batch : nameBatches) {
    allCourses.addAll(courseRepository.findAllByNameIn(batch, Pageable.unpaged()).getContent());
}
// 若需要分页，可对合并后的结果做内存分页，或提前查询符合条件的ID集合后分页

• 临时表方案：如果参数量级特别大，可以先将参数批量插入临时表，再关联临时表做查询，性能远优于分批IN查询。

内容的提问来源于stack exchange，提问作者MelleD