Hibernate 执行相同 SQL 却耗时数分钟，而 SQL 客户端仅需 1.5 秒——核心差异在于：Hibernate 默认全量拉取并映射所有结果集，且使用带参数占位符的 PreparedStatement，可能触发数据库低效执行计划；而 SQL 客户端通常只预取少量行，且以字面量 SQL 执行，获得更优的专属执行计划。
hibernate 执行相同 sql 却耗时数分钟，而 sql 客户端仅需 1.5 秒——核心差异在于：hibernate 默认**全量拉取并映射所有结果集**，且使用带参数占位符的 `preparedstatement`，可能触发数据库低效执行计划；而 sql 客户端通常只预取少量行，且以字面量 sql 执行，获得更优的专属执行计划。
在实际排查中，仅对比“生成的 SQL 文本”是极具误导性的。从你提供的 Hibernate 统计日志可见：
67839913762 nanoseconds spent executing 2 JDBC statements; // ≈ 67.8 秒
而 SQL Developer 中执行看似相同的语句仅需 1.5 秒——这并非 Hibernate “变慢”，而是二者执行语义与行为本质不同。以下是两个最关键的技术动因：
? 1. 结果集遍历深度差异：全量 materialization vs. 懒加载预览
SQL 客户端（如 SQL Developer、DBeaver）默认采用 fetch size 限制 + UI 分页渲染：它可能仅从 ResultSet 中读取前 50–200 行用于显示，后续数据未真正拉取。而 Hibernate 在执行 findAll(Pageable) 时，会完整遍历整个 ResultSet，将每一行转换为 GpCustomer 实体对象，并完成所有字段赋值、代理初始化、二级缓存检查等操作。尤其当表中存在数十万行时（findAll 无 WHERE 条件），即使只请求 PageRequest.of(0, 10)，JPA 默认仍会执行 COUNT(*) + 全表扫描主查询（除非启用 countQuery 优化或使用 @Query(countQuery = "...")），导致 I/O 和 CPU 开销剧增。
✅ 验证方式：
在服务层添加日志，确认是否真在处理全部数据：
public Page<gpcustomer> findAllCustomers() {
Pageable limit = PageRequest.of(0, 10);
Page<gpcustomer> page = gpCustomerRepository.findAll(limit);
log.info("Fetched {} total elements, content size: {}",
page.getTotalElements(), page.getContent().size());
return page;
}</gpcustomer></gpcustomer>
若 totalElements 极大（如 500,000+），则 COUNT(*) 和主查询的全扫描即为性能瓶颈。
⚙️ 2. 执行计划偏差：Parameterized PreparedStatement vs. Literal SQL
Hibernate 底层始终使用 PreparedStatement，例如：
SELECT custno, company FROM GP_CUSTOMER LIMIT ? OFFSET ?
数据库优化器（尤其是 Oracle、SQL Server）面对含 ? 的语句，无法在编译期获知具体参数值，可能选择保守/通用执行计划（如全表扫描而非索引查找），尤其当统计信息陈旧或列选择性差时。而你在 SQL Developer 中粘贴执行的是字面量 SQL：
SELECT custno, company FROM GP_CUSTOMER LIMIT 10 OFFSET 0
优化器可精确估算 LIMIT 10 的低成本，直接选择索引快速定位 + 提前终止，响应自然极快。
✅ 验证方式（以 PostgreSQL 为例）：
分别查看两种语句的执行计划：
-- 字面量 SQL（客户端执行） EXPLAIN ANALYZE SELECT custno, company FROM gp_customer LIMIT 10; -- 参数化 SQL（模拟 Hibernate） PREPARE stmt AS SELECT custno, company FROM gp_customer LIMIT $1; EXPLAIN ANALYZE EXECUTE stmt(10);
若二者 Plan Rows、Actual Total Time 或索引使用明显不同，则证实计划偏差。
✅ 解决方案与最佳实践
| 场景 | 推荐做法 |
|---|---|
| 分页查询必须高效 | ✅ 使用 @Query 显式定义分页查询，避免 findAll(Pageable) 的隐式全表 COUNT： java @Query("SELECT c FROM GpCustomer c") Page 并确保 GP_CUSTOMER 表在 CUSTNO（主键）上有有效索引。 |
| 规避参数化计划劣化 | ✅ 启用数据库级绑定变量窥探（Oracle：OPTIMIZER_ADAPTIVE_FEATURES=TRUE；PostgreSQL：确保 prepare_statement 未过度复用）； ✅ 对关键分页接口，考虑用 @Query(nativeQuery = true) + countQuery 手动控制 COUNT 逻辑。 |
| 验证真实 JDBC 性能 | ✅ 编写最小化 JDBC 测试，严格对齐 Hibernate 行为： java String sql = "SELECT CUSTNO, COMPANY FROM GP_CUSTOMER"; try (PreparedStatement ps = conn.prepareStatement(sql); ResultSet rs = ps.executeQuery()) { while (rs.next()) { /* 必须遍历到底！*/ } } 若此时也达分钟级，则问题在数据库侧（如锁、统计信息、网络延迟）；若仅 1–2 秒，则确认是 Hibernate ORM 层开销。 |
⚠️ 注意：@Data + @Builder 在实体中虽便捷，但若 GpCustomer 关联了其他 @OneToMany 实体却未配置 fetch = FetchType.LAZY，将引发 N+1 查询或意外急切加载，进一步放大延迟。务必审查实体关系注解。
归根结底，Hibernate 不是“慢”，而是功能完备性带来的语义成本。理解其与裸 JDBC 的行为鸿沟，针对性地约束查询范围、优化执行计划、验证真实负载，才能让 JPA 既保持开发效率，又不失生产性能。
