Spring JPA IN运算符偶发参数类型不匹配异常问题

这个偶发的AssertionError是因为Hibernate在解析JPQL的IN子句时，对关联实体参数的类型判断出现了歧义：

• 当使用e.type IN :types时，Hibernate理论上应识别出:types是Type实体列表，但结合(:types IS NULL OR ...)的条件后，Hibernate的参数绑定逻辑偶发出错，把实体列表当成了Type.id的Long类型列表处理，导致绑定参数时类型不匹配。
• 偶发概率问题大概率和Hibernate的查询缓存复用、参数绑定上下文状态有关——部分场景下缓存的查询计划错误复用了之前的参数类型定义，引发参数绑定失败。

1. 明确参数判断逻辑，消除歧义 #

修改JPQL语句，通过实体ID进行过滤，同时用SpEL表达式提前提取实体ID列表，让Hibernate清晰识别参数类型：

@Repository
public interface MyRepository extends JpaRepository<MyEntity, Long> {
    @Query("SELECT COUNT(e) FROM MyEntity e WHERE (:types IS EMPTY OR e.type.id IN :#{#types.![id]})")
    long countByTypesIn(@Param("types") List<Type> types);
}

这里:#{#types.![id]}通过SpEL提取types列表中每个Type对象的id属性，直接传递ID列表给IN子句，彻底避免实体对象与ID类型的混淆。

2. 改用Spring Data JPA动态查询规范（更稳定） #

如果手动JPQL易出问题，推荐使用Specification实现动态过滤，Hibernate的参数绑定逻辑会更可靠：

@Repository
public interface MyRepository extends JpaRepository<MyEntity, Long>, JpaSpecificationExecutor<MyEntity> {
    default long countByTypes(List<Type> types) {
        return count((root, query, cb) -> {
            if (types == null || types.isEmpty()) {
                return cb.conjunction(); // 返回true，不过滤
            }
            return root.get("type").in(types);
        });
    }
}

这种方式由Spring Data JPA自动生成查询语句，参数绑定逻辑更严谨，不会出现类型判断歧义。

3. 排查Hibernate版本与缓存配置 #

• 检查Hibernate版本，部分旧版本（如5.4.x的部分补丁版）存在关联实体IN子句的参数绑定bug，升级到同大版本的最新稳定版（如5.6.15.Final或6.2.x）可解决底层问题。
• 临时禁用查询缓存（在application.properties中设置spring.jpa.properties.hibernate.cache.use_query_cache=false），若问题消失，说明是查询缓存复用导致的参数计划错误，后续可针对性调整缓存策略。

• 避免在JPQL中混合NULL判断和关联实体的IN子句，这种组合易触发Hibernate的参数解析歧义。
• 传递实体列表作为IN子句参数时，尽量明确指定是实体对象还是实体ID，减少Hibernate的自动解析空间。

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