每次写Hibernate系列总有人在评论区和私信里问同一个问题都2025年了Hibernate还有人用吗我一般都会反问一句你所在的公司或者你接触过的项目里Java后端连接数据库有几个是直接裸写JDBC的大多数情况下答案还是落在了JPA/Hibernate这套体系上。即便你用的是MyBatisHibernate所代表的ORM思想和聚合查询模式依然是面试和实际开发绕不开的知识点。今天这篇继续填坑。标题是Hibernate35这次聊聚合函数。在SQL里用count、sum、avg、max、min属于基本操作但在Hibernate里这些聚合操作是通过HQL和Criteria API来完成的写法上有自己的规矩和坑。这篇文章会把常用聚合函数的使用方式、分组聚合、having过滤、返回类型处理以及我在实际项目中踩过的类型不匹配问题一次性讲清楚。1. 为什么ORM框架里也要单独讲聚合查询1.1 聚合查询和普通查询的本质区别普通查询返回的是实体对象比如查User表得到List Hibernate会把每行记录映射成一个User实例。但聚合查询返回的往往不是完整的实体而是某个字段的统计结果、平均值、最大值这类标量值或者是几个字段组合成的统计行。这里就有一个核心矛盾Hibernate的核心理念是面向对象操作数据库但聚合函数本质上是一种面向列的、数学上的计算它和行到对象的映射关系天然不匹配。这就是为什么聚合查询在Hibernate里不能简单用查出List 的思维去写需要引入投影查询和标量返回这两个概念。我见过不少刚接触Hibernate的同事用聚合函数时第一反应是写个HQL查出所有记录然后在Java代码里用循环自己统计。比如查出所有人工资然后for循环一个个加起来求平均。这种写法在数据量小的时候看不出问题但一旦表里几十万行光是在网络传输和内存占用上就非常浪费更不用说Hibernate一级缓存带来的额外开销。正确的做法是让数据库去计算Hibernate只负责把计算结果带回来。数据库的聚合计算是在存储引擎层面完成的效率远高于先把全表数据拉到Java内存里再计算。1.2 HQL聚合查询的三种典型返回形式用HQL写聚合查询返回结果有三种形式这个必须先分清楚否则拿到结果后不知道怎么解析。第一种返回单行单列的标量值。这种情况最常见比如统计用户总数、求某个字段平均值。Hibernate返回的是一个Object对象需要强转成对应的类型。第二种返回单行多列。比如同时查出员工总数和平均薪资HQL里写了两个聚合函数返回值就是一个Object[]数组第一个元素是第一个查询列的值以此类推。第三种返回多行。这种情况通常是配合group by使用每个分组对应一行结果。如果查询列里既有分组字段又有聚合函数那返回的就是ListObject[]每一行是分组字段值加上聚合结果。这里有个很容易踩的坑很多人以为HQL里聚合查询的结果可以自动映射成某个DTO或实体类但实际上Hibernate默认只会返回Object或Object[]除非你用动态实例化语法比如select new com.example.UserCountDTO(department, count(*))这种写法。这个后面详细说。2. 常用聚合函数逐个拆解count、sum、avg、max、min2.1 count统计行数的两个细节count在HQL里的用法和SQL基本一致但有两个细节需要特别注意。第一个细节是count()和count(属性名)的区别。在SQL里count()统计的是所有行数count(某列)统计的是该列非NULL的行数。HQL继承了这一点但写法上有差异。HQL里不能直接写count()更常见的写法是count(id)或者count(u)其中u是实体别名。实际上Hibernate会把count(u)翻译成count(别名对应的主键列)效果等同于count()。如果你确实要统计某列非NULL值的数量就写count(u.email)这样。第二个细节是count返回值的类型。Hibernate把count的结果映射成Long类型这一点和MySQL里count返回BIGINT是对应的。但很多人在Java代码里习惯用int接收结果一跑就报ClassCastException。这个在后面的类型问题章节会专门讲。实际项目中我用得最多的场景是分页前先查总条数。这里有个性能优化的心得如果只是确认是否存在满足条件的记录用count比用list.size()高效得多但更好的做法是HQL里直接写select 1 from Entity where...配合setMaxResults(1)查询或者用exists子查询能够进一步减少数据传输。2.2 sum注意BigDecimal陷阱sum函数用于求和在HQL里写select sum(u.salary) from User u。但这里的类型问题非常操蛋如果salary字段在实体里定义的是BigDecimalsum的结果就是BigDecimal如果字段是Integersum的结果可能是Long如果是Double结果还是Double。问题出在哪个地方呢我遇到过最典型的场景实体里某个金额字段用的是Integer比如单位是分的金额HQL里写sum之后Java端直接拿Long接收没问题。但后来有人把字段类型改成了BigDecimal结果代码里Long接收的地方直接报错。所以用sum的时候最稳妥的做法是统一在HQL里用cast或者直接在Java端用Number类型接收然后调用对应的方法转换。另一个sum相关的坑是空表查询。如果表里一行数据都没有sum的结果是null而不是0。很多人拿到null之后直接参与运算华丽丽地抛出NullPointerException。实际处理中我习惯在HQL里用coalesce函数包一层select coalesce(sum(u.salary), 0) from User u。这样查询结果永远不会是null。2.3 avg精度问题别忽视求平均值在HQL里是select avg(u.score) from ExamResult u。avg函数返回的类型一般是Double即使被求平均的字段是整数。这个在Java端用Double接收没问题。但精度问题要注意如果数据库字段是BigDecimal类型HQL里avg出来的结果可能精度不够精确因为Hibernate底层生成的SQL可能把BigDecimal转成了double进行计算。遇到对精度要求极高的场景比如财务数据我的建议是不要用avg而是用sum和count配合在Java端自己计算平均这样可以自己控制舍入精度和格式。2.4 max和min顺手查极值max和min相对简单返回类型和实体字段类型保持一致。主要用于查最大ID、最早时间、最高分数这类需求。一个实用技巧查最大ID常用于生成下一个流水号或者快速确认表里有没有数据的场景。但直接select max(id)有一个问题如果表数据量巨大走全表扫描的话性能会很差。如果id列有索引数据库一般会走索引扫描来取最大值实测下来速度还可以。但如果你只是想知道表是否有数据max(id)返回null表示没有数据这个判断逻辑在HQL里配合is null判断很直观。3. 分组聚合与having过滤HQL的写法有讲究3.1 group by的写法和注意事项分组聚合在HQL里的基本写法如下String hql select u.department, count(u), avg(u.salary) from User u group by u.department; ListObject[] results session.createQuery(hql).list(); for (Object[] row : results) { String department (String) row[0]; Long count (Long) row[1]; Double avgSalary (Double) row[2]; System.out.println(department - count - avgSalary); }这个写法里有一个必须遵守的规则select后面出现的普通字段非聚合函数包裹的字段必须出现在group by子句中。这一点HQL和SQL是一致的违反的话数据库会直接报错。比如上面这个查询u.department出现在了select里所以group by里必须带上u.department。如果查询里既有普通字段又有聚合函数返回结果是Object[]顺序和select里写的列顺序一一对应。这个顺序很重要代码里取数组下标的时候下标必须按select的顺序来否则取出来的数据就是另一列的了。3.2 having子句分组后过滤的正确姿势很多人在Hibernate里做分组后过滤时第一反应是把条件写在where里结果发现根本不生效。这是因为where是在分组之前过滤的如果过滤条件依赖的是聚合结果比如平均薪资大于10000的部门就必须用having子句。String hql select u.department, avg(u.salary) from User u group by u.department having avg(u.salary) 10000; ListObject[] results session.createQuery(hql).list();这里有一个从SQL继承过来的执行顺序问题where先执行过滤原始行然后group by分组再执行聚合计算最后having过滤分组结果。这个顺序理解到位了写条件就不会放错位置。实际开发中我一般情况下是先写一个不带动态条件的HQL把数据跑出来看看整体分组情况再根据结果决定具体的having条件。因为having条件通常是业务上不确定的动态参数比如查询平均薪资大于某个值的部门这个值是前端传过来的在HQL里拼参数就行了。3.3 多字段分组与排序组合聚合查询里排序也是常见需求。和普通查询一样HQL里用order by排序而且order by子句里可以使用聚合函数别名或者直接使用聚合函数。String hql select u.department, count(u) as cnt from User u group by u.department order by cnt desc;这里顺便说一个HQL的细节如果select里给聚合函数起了别名比如count(u) as cnt这个别名是可以直接在order by和having里用的。但要注意Hibernate对别名的支持在不同版本里有些差异旧的Hibernate版本3.x/4.x在having里用别名偶尔会报错如果你使用的版本较老保险起见having里直接重复写聚合函数表达式。排序还有一个实用场景分页查询配合聚合。比如要查数量最多的前10个分类可以在聚合查询上直接setMaxResults(10)Hibernate会生成带有limit的SQL。这个分页对聚合查询是有效的数据库层面只会计算需要的分组。4. 通过一条完整案例串起所有知识点4.1 业务场景描述为了把前面零散的知识点串起来这里用一个完整的业务案例。假设我们有一个在线教育系统需要统计每个课程类目下的销售情况。两张表Category类目表和CourseOrder订单表。订单表通过course_id关联到课程再通过课程关联到类目。现在业务方要一个报表每个一级类目下的订单总数、总销售额、平均客单价、最大单笔订单金额。这个需求如果用原生SQL写就是一个普通的联表分组聚合。但放到Hibernate里有几种不同的写法涉及的关联查询和聚合组合值得完整走一遍。4.2 实体关联设计订单实体和课程实体的关联关系大概如下Entity Table(name course_order) public class CourseOrder { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; ManyToOne JoinColumn(name course_id) private Course course; Column(name order_amount) private BigDecimal orderAmount; // getter/setter省略 }课程实体里有关联的类目Entity Table(name course) public class Course { Id private Long id; Column(name name) private String name; ManyToOne JoinColumn(name category_id) private Category category; // getter/setter省略 }类目实体Entity Table(name category) public class Category { Id private Long id; Column(name name) private String name; // getter/setter省略 }有了这三层关联用HQL写聚合查询时可以充分利用Hibernate的对象导航能力。比如直接从CourseOrder出发通过course.category.name拿到类目名称这就是HQL和原生SQL最大的区别之一。4.3 完整HQL聚合查询实现String hql select c.category.name, count(o), sum(o.orderAmount), avg(o.orderAmount), max(o.orderAmount) from CourseOrder o join o.course c group by c.category.name; ListObject[] reportData session.createQuery(hql).list();这段HQL里有很多值得说的点。第一使用了隐式关联。CourseOrder实体里的course字段已经关联了CourseCourse里又关联了Category所以在HQL里可以直接写c.category.name来导航到类目名称Hibernate会自动生成表关联的SQL。但注意如果导航路径太长比如三层以上生成的SQL会变成多个inner join性能上需要评估。我一般超过两层关联就建议用显式join。第二join o.course c这句的作用。HQL里写join o.course c相当于告诉Hibernate把CourseOrder和Course做关联并且给Course起了一个别名c。这样在group by里才能简洁地使用c.category.name。如果不写join直接在HQL的from里写CourseOrder o那么o.course.category.name也能通过隐式导航查出来Hibernate会自动生成join。但显式写join语义更清晰而且能明确join类型inner、left等。第三count(o)统计的是订单数。因为一行记录对应一个订单实体count(o)的效果等同于count(*)。这里不能写count(o.course)因为如果course为null理论上订单必须有课程但业务上可能有脏数据count(o.course)会把null值的行过滤掉导致订单数变少。这个细节很容易被忽略。4.4 报表查询参数化与动态拼接实际情况中这个报表通常还有筛选条件比如统计某个时间段内的订单。直接在HQL里拼参数StringBuilder hqlBuilder new StringBuilder(); hqlBuilder.append(select c.category.name, count(o), sum(o.orderAmount), ); hqlBuilder.append(avg(o.orderAmount), max(o.orderAmount) ); hqlBuilder.append(from CourseOrder o join o.course c ); hqlBuilder.append(where o.createdTime :startTime and o.createdTime :endTime ); hqlBuilder.append(group by c.category.name order by count(o) desc); QueryObject[] query session.createQuery(hqlBuilder.toString()); query.setParameter(startTime, startTime); query.setParameter(endTime, endTime); ListObject[] reportData query.list();这里用了命名参数:startTime和:endTimeHibernate会帮你做参数绑定避免SQL注入问题。HQL里禁止用?这种位置参数某些版本虽然支持但已经是废弃行为新代码一律用命名参数。动态拼接HQL时还要注意一个细节如果where条件不固定比如时间段是可选的那么拼接时where和and之间的处理容易出错。我自己的习惯是先把所有可能的条件存到一个List 里然后再拼起来。比如ListString conditions new ArrayList(); if (startTime ! null) { conditions.add(o.createdTime :startTime); } if (endTime ! null) { conditions.add(o.createdTime :endTime); } if (!conditions.isEmpty()) { hqlBuilder.append( where ).append(String.join( and , conditions)); }这样就不会出现where后面直接跟and或者没有where却有and这种低级错误。4.5 用DTO投影消除Object[]下标魔法老实说上面这种Object[]处理方式在代码里算是能跑但很丑的典型代表。数组下标取值的可读性极差只要查询列的顺序一变所有取值的下标都要跟着改维护成本很高。更好的方案是用HQL的动态实例化语法直接把查询结果映射到一个DTO对象。先定义一个统计报表DTOpublic class CategoryOrderReport { private String categoryName; private Long orderCount; private BigDecimal totalAmount; private BigDecimal avgAmount; private BigDecimal maxAmount; public CategoryOrderReport(String categoryName, Long orderCount, BigDecimal totalAmount, BigDecimal avgAmount, BigDecimal maxAmount) { this.categoryName categoryName; this.orderCount orderCount; this.totalAmount totalAmount; this.avgAmount avgAmount; this.maxAmount maxAmount; } // getter/setter省略 }然后HQL改为String hql select new com.example.dto.CategoryOrderReport(c.category.name, count(o), sum(o.orderAmount), avg(o.orderAmount), max(o.orderAmount)) from CourseOrder o join o.course c group by c.category.name; ListCategoryOrderReport reports session.createQuery(hql).list();这里有几个强制要求要记牢。DTO的构造器参数顺序必须和select里的列顺序完全一致。构造器参数类型必须和查询结果的类型匹配比如count(o)返回Long构造器第二个参数就得是Long不能写Integer。还有DTO的全限定类名必须写完整Hibernate不会去自动import。用DTO投影的好处很明显查询结果的类型是安全的不再需要手动强转代码可读性也高了很多。团队成员接手的时候看一眼DTO构造器就知道查询返回了什么。这个写法在我目前参与的项目里是聚合查询的首选方案。5. 聚合查询的常见翻车现场与排查思路5.1 ClassCastException类型映射不一致这是聚合查询里最常见的运行时异常。前面多次提到count返回Longsum根据字段类型变avg基本都是Double。如果代码里用错误的类型去接收ClassCastException当场爆发。排查方法很简单先写一段打印日志的代码直接输出session.createQuery(hql).list()拿到的每个元素的getClass().getName()一眼就能看出真实类型是什么。比如打印出来是java.lang.Long但代码里强转成Integer马上就能定位问题。预防措施写聚合查询前先确认实体字段类型再推断聚合结果的类型。count就默认Longsum和字段类型强相关avg默认Doublemax/min跟字段类型一致。拿不准就用Object接然后打印getClass()。5.2 空结果集返回null导致NPE聚合查询在没有数据可查时sum、avg、max、min都可能返回null。比如查询某用户的总消费金额如果这个用户从未下过单sum的结果就是null而不是0。不少人拿到null后直接和其他数字运算NPE就来了。我在项目里定过一个规矩所有可能返回null的聚合查询如果有为0更合理的业务语义统一在HQL里用coalesce处理select coalesce(sum(o.orderAmount), 0) from CourseOrder o where o.user.id :userId这样Java端拿到的永远是BigDecimal.ZERO不用在业务代码里做一层null判断。但要注意coalesce要求所有参数类型一致比如sum返回BigDecimal0要写成BigDecimal.ZEROHQL里可以直接写0Hibernate会尝试做类型转换。5.3 HQL里用了select *和普通字段混搭聚合查询里不能混用普通字段和聚合字段而不分组。比如这么写select u, count(u.department) from User u group by u.department数据库会报错select列表中的字段没有出现在group by里。因为u代表整个实体对应所有列数据库没法知道该按哪个分组。解决办法要么select里只放分组字段和聚合函数要么把整个实体放在group by里group by u会按主键分组业务上通常没有意义。5.4 大小写和关键字冲突问题HQL里查询的表名和字段名对应的是实体类和属性名不是数据库表名和列名。Entity名和属性名区分大小写。比如实体类叫CourseOrderHQL里写from courseorder就会报错。属性名同理orderAmount和orderamount是两个东西。还有一个容易踩的坑如果实体属性名和HQL关键字冲突比如有个属性叫orderHQL里select o.order这种写法可能会报语法错误。遇到这种情况要么改实体的字段映射名要么用反引号转义Hibernate支持SQL风格的反引号但用起来很别扭。我一般建议直接改实体属性名一劳永逸。5.5 N1查询问题在聚合场景的放大效应分组聚合查询用left join关联实体时如果结果集很大Hibernate可能会因为懒加载触发N1查询。比如上面的报表查询如果Category的name是懒加载的不太常见但存在那每一行分组结果都可能触发一次额外查询。实际情况中聚合查询本身用的是joinHibernate生成的SQL已经是一次性把关联数据查出来了。但如果实体关系里配置了ManyToOne(fetch FetchType.LAZY)而在HQL的select里直接导航c.category.nameHibernate会尝试通过join一次性取回来这里通常没问题。真正的N1隐患在于你先把聚合查询的结果返回了Object[]然后在Java代码里通过对象数组里某个ID再去访问关联实体的懒加载属性。所以基本原则查询完立即访问需要的关联属性或者在HQL里显式join fetch预加载或者干脆把实体关联改成默认非懒加载。6. 回到那个问题Hibernate还有人用吗6.1 存量系统和招聘市场的现状每次写这种偏底层的Hibernate技巧文章都有人质疑学这个还有没有用。实际情况是存量系统的体量远超很多人的想象。多家大型传统企业的核心交易系统、银行内部系统、政务平台用的是基于Hibernate的老框架比如Spring Struts Hibernate的组合这些系统不会因为MyBatis流行就推倒重写。只要这些系统还在运行就需要有人看得懂HQL、修得了聚合查询。招聘市场上一些大厂的Java岗位虽然JD里写着MyBatis但面试连环追问里仍然会出现JPA/Hibernate的问题。原因很简单JPA是JavaEE的官方规范而Hibernate是JPA最主流的实现Spring Data JPA底层就是Hibernate。你学Spring Boot的时候几乎绕不开spring-boot-starter-data-jpa这个依赖而这个依赖默认就带着Hibernate。6.2 技术选型的个人观点我不太赞成必选某一种框架的说法。MyBatis在SQL控制力上有优势适合查询复杂、优化空间大的系统Hibernate在开发效率、对象关系映射、缓存管理上有优势适合业务逻辑复杂、表关系清晰的系统。两者各有各的适用场景。但有一点是确定的Hibernate的聚合查询和HQL写法反映的是ORM框架对面向对象与关系型数据库之间阻抗不匹配的一种具体处理方式。理解这个过程对后面应付Spring Data JPA的Query注解、Specification动态查询、甚至理解MyBatis的association和collection映射都有直接的帮助。这些框架本质都是在解决同一个问题让Java代码和数据库之间有一座更省力的桥。6.3 这篇文章能直接带走的东西聚合查询这件事归纳起来就几个要点。HQL里count返回Longsum和avg要注意类型和null值max和min最简单。分组聚合必须带group byhaving是分组后的过滤条件写的时候注意和where的执行顺序区分。查询结果要么用Object[]要么用DTO投影团队协作强烈建议DTO方案。动态条件拼接用命名参数条件列表先存再拼避免拼接错误。这几条都是我在实际项目里一条一条踩出来的。希望这篇能帮你少踩几个坑。如果后续想深入可以把Criteria API的聚合查询比如CriteriaBuilder的sum、avg也展开讲讲那个在动态查询场景下比HQL拼接字符串要安全得多。