使用JPQL与Spring带可选参数时查询性能异常缓慢的原因咨询

这种现象主要和JPA框架的参数处理逻辑、数据库执行计划的生成与缓存机制直接相关，具体可以拆解为以下几点：

• 执行计划缓存不匹配
  Hibernate会缓存生成的SQL执行计划，但你的JPQL写法会生成包含多个OR分支的SQL，当参数组合变化（比如部分参数为null、部分不为）时，数据库的执行计划缓存可能无法复用最优计划。比如第一次执行时参数全为null，数据库生成全表扫描的计划；后续传入非null参数时，可能仍复用这个低效计划，导致执行变慢。而你单独执行SQL时，参数是固定的，数据库能直接生成针对该参数的最优执行计划。

• 数据库优化器的决策偏差
  带有(:param IS NULL OR e.column = :param)的条件会让数据库优化器难以准确评估统计信息。优化器可能无法判断某个条件是否会被触发，为了覆盖所有可能的参数情况，会选择保守的执行策略（比如放弃索引扫描，改用全表扫描）。而移除OR子句后，条件明确，优化器能精准选择索引，查询自然变快。

• 绑定变量窥探的副作用
  部分数据库（如Oracle、MySQL）存在绑定变量窥探机制：第一次执行带绑定变量的SQL时，会根据传入的实际参数值生成执行计划，后续执行复用该计划。如果第一次执行时传入的参数是null，生成的计划是全表扫描；之后即使传入非null参数，也会复用这个低效计划，导致应用中执行缓慢。而单独执行SQL时用的是硬编码的具体值，优化器能重新生成最优计划。

• JPA框架的额外处理开销
  Hibernate在处理这种动态条件时，会增加参数解析、条件判断的额外逻辑。比如在SQL执行前后，需要判断每个参数是否为null，再决定是否应用对应的过滤条件，这部分逻辑会占用应用端的CPU和时间，叠加数据库端的低效执行，就会导致整体耗时大幅上升。

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