如何分析JPA/Hibernate数据库查询效率及排查慢查询

1. 先揪出实际执行的SQL并分析数据库层面耗时 #

开启Hibernate的SQL日志，获取完整带参数的执行语句，直接拿到PostgreSQL客户端执行并查看执行计划：

• 配置日志输出（application.yml）：

  logging:
    level:
      org.hibernate.SQL: DEBUG
      org.hibernate.type.descriptor.sql.BasicBinder: TRACE
  

• 把日志里的SQL复制出来，用EXPLAIN ANALYZE执行，重点看：
  • 是否走了预期的索引，有没有出现全表扫描
  • left join fetch是否导致结果集行数暴增（比如一对多关联产生笛卡尔积）
  • 两个查询的执行计划差异（和快的ScheduledLeg查询对比）

2. 验证缓存对查询的影响 #

• 清空Hibernate一级缓存：调用EntityManager.clear()后重新执行慢查询，排除Session级缓存的干扰
• 临时禁用二级缓存：将hibernate.cache.use_second_level_cache设为false，测试耗时变化
• 反向测试：先执行慢查询，再执行快查询，看后者是否依然快，排除PostgreSQL共享缓存预热的影响

3. 排查实体实例化的开销 #

• 对比两个查询返回的实际行数：看似数据量相似，left join fetch可能因为关联对象导致返回重复行，实际实例化的对象数远多于ScheduledLeg查询
• 单独测试对象实例化耗时：手动创建相同数量的BookingLegEntity和ScheduledLegEntity，对比初始化时间，判断是否是实体结构复杂（字段多、关联深）导致的开销
• 临时移除left join fetch b.belongsTo，仅查询BookingLegEntity本身，看耗时是否下降，确认是否是关联对象加载导致的问题

4. 优化@Query写法并验证 #

• 调整关联查询写法：把b.distributor.id = ?3改为join b.distributor d where d.id = ?3，避免Hibernate隐式生成低效的关联逻辑
• 检查字段类型匹配：确认startTimewindowStart的Instant类型和数据库timestamp with time zone字段完全匹配，避免类型转换导致索引失效
• 改用命名参数：替换位置参数为@Param("from")等命名参数，避免参数顺序错误引发的潜在问题

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