使用Entity Graph优化JPA查询（graphql jpa）

本文由 Tony's Toy Blog 版权所有。如若转载，请注明出处，原文链接见文章底部了解更多。

概述

JPA(Java Persistent API)作为java的官方实体映射API与Hibernate基本是一脉相承，大部分情况下还是采用Hibernate作为JPA的实现。Hibernate作为一款全自动ORM框架，基本上屏蔽了对原生SQL的操作，再加上自动更新数据表结构，就编码完成指定内容这一项来说确实是很舒服，但是舒服还是有不小的性能代价，这也使得半自动ORM框架(主要是mybatis)在对性能要求较高的互联网企业应用更多一些。

JPA的应用同样存在Hibernate的痛点，最重要的原因之一就是发送过多的SQL获取内容，其中最著名的便是n+1问题。JPA2.1版本增加了几个提升应用性能的新内容，包括Entity Graph、Criteria Update/Delete以及动态存储过程查询等，这其中针对发送过多SQL的问题的便是Entity Graph。

应用环境

在如今各种脚手架大行其道的状况下，日常的工作时有码畜的感觉，不过也不得不感慨这些脚手架巨大的威力，显著提高了生产效率。在JAVA开发这块Spring几乎是无所不在、无所不能，在持久化这块Spring也已经“拿下”，并且非常优秀，spring-data-**这一系列包对各种接口、框架、数据源进行了封装整合，与JPA相关的便是spring-data-jpa。

spring-data-jpa相对于Hibernate原生操作更进一层，相对于原生的Hibernate操作优雅了好几个级别，对于小项目来说确实是个大杀器。同样的，对于快速搭建一个应用spring-boot更是一个终极杀器，本篇内容就基于spring-boot(1.5.9)、spring-data-jpa(1.11.9)和mysql，对应的Hibernate版本为5.0.12.Final。

应用问题

工具越方便，应用就越奔放，对于具有一定复杂度地项目来说，为了方便和直观很容易在设计实体类的时候建立长串的关联关系，而且都是双向关联，在不加处理的情况下对于一个实体类的查询可能会引发无数条SQL，序列化一个实体类时再次引发无数条SQL甚至可能死循环，如果开启sql语句打印到控制台将会满屏眼花缭乱。

通常来说，根据要求控制关联对象的Fetch类型和DTO的转换可以减少很多无用的SQL语句，但是如果关联层次很深依然不好控制，还是有可能出现满屏飞奔的SQL语句。此外，针对同一个实体的查询，可能需要获取不同内容的结果，比如A关联B，B关联C，查询A时有时候需要同时获取B和C，也有情况下只需要获取B，这样在实体层面指定Fetch类型并不能满足需求。

如果真的有性能要求，在之前应该是只能采用直接编写HQL(JPQL)或者原生SQL的方式来解决，但是这样总是有些违背框架初衷以及面向对象的要求，再加上分页以及返回值的封装要求，就会非常不舒服。

实体图概念

Entity Graph简单翻译为实体图，不过感觉加载图这个称呼可能更加符合一些。官方文档中Entity Graph可以解释为针对特定持久化查询或操作的模板，常常用于创建实体的抓取策略。简单来说Entity Graph可以指定如何获取实体以及实体关联的实体，就好比一张图一般。

实体图应用

创建实体图可以使用代码或者注解，一般来说使用注解，代码的方式不直观而且不方便。

// 代码创建
EntityGraph<YourEntity> eg = em.createEntityGraph(YourEntity.class);
eg.addAttributeNodes("body");
// more attributes...

//========================================================

// 注解创建
@Entity
@NamedEntityGraphs(value = {
        @NamedEntityGraph(name = "graphName", attributeNodes = {
                @NamedAttributeNode(value = "body", subgraph = "bodySub"),
                // more attributes...
        },subgraphs = {
                @NamedSubgraph(name = "bodySub", attributeNodes = {
                        @NamedAttributeNode(value = "part", subgraph = "partSub"),
                        // more attributes...
                }),
                // more subgraphs...
        })
        // more graphs...
})
public class YourEntity{
  // attributes...
}

可以看到注解的形式是注解在实体类上的，一个实体图由一个@NamedEntityGraph注解表示，使用@NamedAttribute来指定要加载的字段，如果加载的字段还需要加载子字段，那么可以使用@NamedSubgraph添加子图并且使用subgraph这个属性进行指定，子图中的节点可以指定另外的子图作为subgraph值，这样通过@NamedAttributeNode和@NamedSubgraph就可以完整地描述一幅实体图。

根据官方文档的描述，实体图可以有两种应用方式，分别是提取图（fetch graph）和负载图（load graph）。Fetch Graph将会急加载指定的字段，其余字段将忽略原来的加载类型；Load Graph将会急加载指定的字段，其余字段按原来默认的属性加载。

应用实体图时，可以直接在Repository接口方法上进行注解，如果图比较简单，也可以直接在注解上写明属性路径，这样就不需要编写实体图。在使用EntityManager直接进行查询时可以将Entity Graph作为QueryHint进行输入。

@Repository
public interface GroupRepository extends CrudRepository<GroupInfo, String> {
  
  @EntityGraph(value = "GroupInfo.detail", type = EntityGraphType.FETCH)
  GroupInfo getByGroupName(String name);
  
  @EntityGraph(attributePaths = { "members" })
  GroupInfo getByGroupType(String type);
}

//=========================================================

EntityGraph<GroupInfo> eg = em.getEntityGraph("GroupInfo.detail");
List<GroupInfo> groupInfos = em.createNamedQuery("findAllGroupInfos")
        .setHint("javax.persistence.fetchgraph", eg)
        .getResultList();

实体图插件

spring-data的Repository接口应用是十分强大、便捷的，根据方法名直接解析查询是其中很大的一个亮点，很多时候基本上不会直接去操作EntityManager。那么对于@EntityGraph这个注解就有个比较尴尬的问题，比如上述的getByGroupName这个方法，如果想要指定不同的实体图就不得不去创建多个包含getByGroupName方法的GroupRepository。

如果能将实体图作为方法参数就好了！也确实有人向spring提过这个问题，比较奇怪的是官方并没有改进的意思。不过幸好有第三方实现了这个需求：spring-data-jpa-entity-graph（github），用起来还是非常舒服的，具体应用方式请参考它的文档。

存在的问题以及注意事项

在应用过程中并不是一帆风顺，出了很多幺蛾子令我很头疼，主要有如下几点：

1. 提取图（fetch graph）和负载图（load graph）没有看到应有的区别，尽管采用了提取图，不在图中的默认急加载字段还是发送了额外的SQL。这是个非常严重的问题，意味着如果要在这种情况下应用实体图，实体所有字段都要设置为默认懒加载，也造成如果对一个实体应用实体图，那么与这个实体在同一个关联链路上的其他所有实体基本上都要编写对应的实体图进行控制。
2. 无法指定急加载的形式，字段一旦编入实体图，就会采用Join的形式急加载，无法指定为立刻发送额外SQL的形式。这也是一个比较严重的问题，在分页的情况下是不应该采用Join的形式加载集合字段的，Hibernate可能会发出警告：firstResult/maxResults specified with collection fetch; applying in memory!，这表示无法在数据库层面的进行分页，查询获取所有结果后在内存中进行分页处理，性能反而急剧下降。这意味着如果要应用于分页，就不能把集合字段编入实体图，而在上述问题下字段都必须默认懒加载，这样如果要精确控制，集合字段就无论如何无法用额外SQL形式急加载。
3. 无法指定子类的属性。如果存在继承映射（SINGLE_TABLE）的情况且父类作为实体的一个字段，实体图无法指定属于子类的字段。
4. 因为xToOne的成员也全部设置为lazy加载，如果需要序列化这些对象（实际上是Hibernate代理），可能需要额外进行处理，例如使用HibernateProxy接口进行转换。
5. 关联关系复杂的情况下，实体图注解会非常庞大，影响实体类的观感。实体类上的实体图无法复用，不能作为其他图的子图。个人觉得实体图这种形式，编写XML或许会更加合适，表达也更清晰，不过好像没有现成的实现。

总之Entity Graph还是有一定用武之地的，确实可以达到在不编写SQL、JPQL的情况下一个请求发一个SQL的要求，对于强迫症来说也是个福音…只是可能还不够成熟吧。