N+1 SELECT问题真的很难发现，尤其是在具有大型域的项目中，当它开始降低性能时。即使问题得到解决，即通过添加紧急加载，进一步的开发可能会破坏解决方案和/或在其他地方再次引入N+1 SELECT问题。

我创建了开源库jplusone来解决基于JPA的Spring Boot Java应用程序中的这些问题。该库提供两个主要功能：

生成将SQL语句与触发它们的JPA操作的执行相关联的报告，并将其放置在应用程序的源代码中

2020-10-22 18:41:43.236 DEBUG 14913 --- [           main] c.a.j.core.report.ReportGenerator        :
    ROOT
        com.adgadev.jplusone.test.domain.bookshop.BookshopControllerTest.shouldGetBookDetailsLazily(BookshopControllerTest.java:65)
        com.adgadev.jplusone.test.domain.bookshop.BookshopController.getSampleBookUsingLazyLoading(BookshopController.java:31)
        com.adgadev.jplusone.test.domain.bookshop.BookshopService.getSampleBookDetailsUsingLazyLoading [PROXY]
            SESSION BOUNDARY
                OPERATION [IMPLICIT]
                    com.adgadev.jplusone.test.domain.bookshop.BookshopService.getSampleBookDetailsUsingLazyLoading(BookshopService.java:35)
                    com.adgadev.jplusone.test.domain.bookshop.Author.getName [PROXY]
                    com.adgadev.jplusone.test.domain.bookshop.Author [FETCHING ENTITY]
                        STATEMENT [READ]
                            select [...] from
                                author author0_
                                left outer join genre genre1_ on author0_.genre_id=genre1_.id
                            where
                                author0_.id=1
                OPERATION [IMPLICIT]
                    com.adgadev.jplusone.test.domain.bookshop.BookshopService.getSampleBookDetailsUsingLazyLoading(BookshopService.java:36)
                    com.adgadev.jplusone.test.domain.bookshop.Author.countWrittenBooks(Author.java:53)
                    com.adgadev.jplusone.test.domain.bookshop.Author.books [FETCHING COLLECTION]
                        STATEMENT [READ]
                            select [...] from
                                book books0_
                            where
                                books0_.author_id=1

提供API，允许编写测试，检查应用程序使用JPA的效率（即断言延迟加载操作的数量）

@SpringBootTest
class LazyLoadingTest {

    @Autowired
    private JPlusOneAssertionContext assertionContext;

    @Autowired
    private SampleService sampleService;

    @Test
    public void shouldBusinessCheckOperationAgainstJPlusOneAssertionRule() {
        JPlusOneAssertionRule rule = JPlusOneAssertionRule
                .within().lastSession()
                .shouldBe().noImplicitOperations().exceptAnyOf(exclusions -> exclusions
                        .loadingEntity(Author.class).times(atMost(2))
                        .loadingCollection(Author.class, "books")
                );

        // trigger business operation which you wish to be asserted against the rule,
        // i.e. calling a service or sending request to your API controller
        sampleService.executeBusinessOperation();

        rule.check(assertionContext);
    }
}

这是对问题的一个很好的描述

现在您了解了这个问题，通常可以通过在查询中执行连接获取来避免。这基本上强制获取延迟加载的对象，因此数据在一个查询中而不是n+1个查询中检索。希望这有帮助。

Hibernate和Spring数据JPA中的N+1问题

N+1问题是对象关系映射中的一个性能问题，它为应用层的单个选择查询在数据库中触发多个选择查询（准确地说是N+1，其中N=表中的记录数）。Hibernate&Spring Data JPA提供了多种方法来捕获和解决这个性能问题。

什么是N+1问题？

为了理解N+1问题，让我们考虑一个场景。假设我们有一个映射到数据库中DB_User表的User对象集合，每个用户都有一个使用联接表DB_User_Role映射到DB_Role表的集合或角色。在ORM级别，用户与角色具有多对多关系。

Entity Model
@Entity
@Table(name = "DB_USER")
public class User {

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    private Long id;
    private String name;

    @ManyToMany(fetch = FetchType.LAZY)                   
    private Set<Role> roles;
    //Getter and Setters 
 }

@Entity
@Table(name = "DB_ROLE")
public class Role {

    @Id
    @GeneratedValue(strategy= GenerationType.AUTO)
    private Long id;

    private String name;
    //Getter and Setters
 }

一个用户可以有许多角色。角色加载缓慢。现在假设我们想从这个表中获取所有用户，并为每个用户打印角色。非常幼稚的对象关系实现可能是-具有findAllBy方法的UserRepository

public interface UserRepository extends CrudRepository<User, Long> {

    List<User> findAllBy();
}

ORM执行的等效SQL查询为：

首先获取所有用户（1）

Select * from DB_USER;

然后获取每个用户执行N次的角色（其中N是用户数）

Select * from DB_USER_ROLE where userid = <userid>;

因此，我们需要为User选择一个选项，为每个用户提取角色选择N个选项，其中N是用户总数。这是ORM中的一个经典N+1问题。

如何识别？

Hibernate提供了跟踪选项，可以在控制台/日志中启用SQL日志记录。使用日志，您可以很容易地看到hibernate是否为给定的调用发出N+1个查询。

如果您在给定的select查询中看到多个SQL条目，那么很可能是由于N+1问题。

N+1分辨率

在SQL级别，ORM要避免N+1，需要实现的是启动一个连接两个表的查询，并在单个查询中获得组合结果。

获取联接SQL，用于检索单一查询中的所有内容（用户和角色）

OR普通SQL

select user0_.id, role2_.id, user0_.name, role2_.name, roles1_.user_id, roles1_.roles_id from db_user user0_ left outer join db_user_roles roles1_ on user0_.id=roles1_.user_id left outer join db_role role2_ on roles1_.roles_id=role2_.id

Hibernate和Spring Data JPA提供了解决N+1 ORM问题的机制。

1.弹簧数据JPA方法：

如果我们使用的是SpringDataJPA，那么我们有两个选项来实现这一点-使用EntityGraph或使用带有fetch连接的select查询。

public interface UserRepository extends CrudRepository<User, Long> {

    List<User> findAllBy();             

    @Query("SELECT p FROM User p LEFT JOIN FETCH p.roles")  
    List<User> findWithoutNPlusOne();

    @EntityGraph(attributePaths = {"roles"})                
    List<User> findAll();
}

N+1个查询在数据库级别使用左连接获取发出，我们使用attributePaths解决N+1问题，Spring Data JPA避免N+1问题

2.休眠方法：

如果它是纯Hibernate，那么以下解决方案将起作用。

使用HQL：

from User u *join fetch* u.roles roles roles

使用标准API：

Criteria criteria = session.createCriteria(User.class);
criteria.setFetchMode("roles", FetchMode.EAGER);

所有这些方法的工作原理都类似，它们使用左连接获取发出类似的数据库查询

在Phabricator文档中可以找到问题的简短解释：

N+1查询问题是一个常见的性能反模式。它看起来像这样：$cats=load_cats（）；foreach（$cat作为$cat）{$cats_hats=>load_hats_for_cat（$cat）；// ...}假设load_cats（）的实现归结为：从猫的位置选择*。。。..和load_hats_for_cat（$cat）的实现如下：SELECT*FROM hat WHERE catID=。。。..当代码执行时，您将发出“N+1”个查询，其中N是猫的数量：从猫的位置选择*。。。SELECT*FROM hat WHERE catID=1SELECT*FROM hat WHERE catID=2SELECT*FROM hat WHERE catID=3从帽子中选择*，其中catID=4...

解决方案：

发出一个返回100个结果的查询比发出发出100个查询，每个查询返回1个结果。

在迭代之前加载所有数据。

假设您有一组Car对象（数据库行），每个Car都有一组Wheel对象（也有行）。换句话说，汽车→ 轮子是一对多的关系。

现在，假设您需要遍历所有汽车，并为每辆汽车打印出车轮列表。天真的O/R实现将执行以下操作：

SELECT * FROM Cars;

然后，对于每辆车：

SELECT * FROM Wheel WHERE CarId = ?

换言之，您可以为汽车选择一个选项，然后再选择N个选项，其中N是汽车的总数。

或者，可以获取所有轮子并在内存中执行查找：

SELECT * FROM Wheel;

这将到数据库的往返次数从N+1减少到2。大多数ORM工具提供了几种防止N+1选择的方法。

参考资料：Java Persistence with Hibernate，第13章。

N+1选择问题是一个难题，在单元测试中检测这种情况是有意义的。我已经开发了一个小型库，用于验证给定测试方法或任意代码块执行的查询数量-JDBC Sniffer

只需在测试类中添加一个特殊的JUnit规则，并在测试方法上放置带有预期查询数的注释：

@Rule
public final QueryCounter queryCounter = new QueryCounter();

@Expectation(atMost = 3)
@Test
public void testInvokingDatabase() {
    // your JDBC or JPA code
}