Oracle下count(*)被Hibernate包装成子查询易致全表扫描，因优化器难估算嵌套查询成本；应调大plan_cache_max_size、更新统计信息、避免冗余JOIN，必要时用原生SQL。
Oracle下count(*)被Hibernate包装成子查询导致全表扫描
hibernate默认对jpql或criteria的count()操作生成嵌套子查询，比如把select count(*) from (select ...)这种结构交给oracle执行。oracle优化器对这类外层count(*)常无法准确估算，尤其当内层查询含join、order by或复杂where时，容易放弃使用索引而走全表扫描——原生sql直接写select count(*) from t_user where status = 1则大概率命中索引。
实操建议：
- 用
EXPLAIN PLAN FOR对比两者的执行计划，重点关注OBJECT_NAME和OPERATION是否出现FULL扫描 - 检查Hibernate生成的SQL（开启
spring.jpa.show-sql=true+logging.level.org.hibernate.type=trace） - 避免在
count()中引入不必要的JOIN，改用@Formula或数据库视图预计算关联字段
hibernate.query.plan_cache_max_size过小引发重复解析
Hibernate会缓存HQL/Criteria对应的SQL模板，但Oracle对绑定变量+动态SQL的硬解析开销比MySQL高得多。若hibernate.query.plan_cache_max_size设得太小（默认2048），频繁的count查询可能反复触发Oracle的SQL解析与执行计划生成，拖慢响应。
实操建议：
- 将
hibernate.query.plan_cache_max_size调大到8192或更高，观察v$sql中PARSE_CALLS是否下降 - 确认连接池（如HikariCP）启用了
cachePrepStmts=true，避免驱动层重复prepare - 对固定条件的分页count，可考虑用
@NamedQuery替代动态Criteria，提升缓存命中率
Oracle统计信息陈旧导致执行计划劣化
Hibernate生成的count语句依赖Oracle优化器选择路径，而优化器严重依赖表/索引的统计信息。如果DBA_TAB_STATISTICS里LAST_ANALYZED是几个月前的，优化器可能误判数据分布，给子查询分配错误的驱动表顺序或忽略索引。
实操建议：
- 运行
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'TABLE_NAME');更新关键表统计信息 - 对高频count的字段组合（如
status, create_time），建立复合索引并收集列级统计：DBMS_STATS.GATHER_COLUMN_STATS - 避免在应用启动时自动触发
hibernate.hbm2ddl.auto=update，它不会刷新统计信息，反而可能干扰DBA维护节奏
原生SQL绕过Hibernate映射开销但失去可移植性
直接用EntityManager.createNativeQuery("select count(*) from ...")能跳过HQL解析、实体映射、二级缓存校验等环节，性能提升明显。但它把数据库方言锁死，且无法复用JPA的事务上下文自动传播（需显式声明@Transactional）。
实操建议：
- 仅对QPS高、逻辑稳定、不跨库的count场景用原生SQL，例如后台报表的总数统计
- 用
@NamedNativeQuery代替字符串拼接，便于单元测试和SQL审计 - 注意Oracle的
ROWNUM伪列不能用于count(*)结果过滤，别误写成where rownum 再套count
最麻烦的不是慢，而是慢得不透明——Hibernate把SQL生成、参数绑定、结果集转换全包在黑盒里，出问题时得一层层拆开看执行计划、统计信息、缓存配置。Oracle环境下，宁可多花十分钟查v$sql_plan，也别靠猜。
