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);
    }
}

假设您有一组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章。

以Matt Solnit为例，假设您将Car和Wheels之间的关联定义为LAZY，并且需要一些Wheels字段。这意味着在第一次选择后，休眠将为每辆车执行“select*from Wheels where car_id=：id”。

这使得每个N辆车的第一次选择和更多的1次选择，这就是为什么它被称为N+1问题的原因。

为了避免这种情况，请使关联获取变得急切，以便hibernate使用连接加载数据。

但请注意，如果您多次无法访问关联的Wheels，最好将其保持为LAZY或使用Criteria更改获取类型。

在不深入技术堆栈实现细节的情况下，从架构上讲，N+1问题至少有两种解决方案：

只有1个-大查询-带有联接。这使得大量信息从数据库传输到应用程序层，特别是如果有多个子记录。数据库的典型结果是一组行，而不是对象图（有不同的DB系统的解决方案）有两个（或更多需要连接的子级）查询-1个用于父级，在有了它们之后-通过ID查询子级并映射它们。这将最大限度地减少DB和APP层之间的数据传输。

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

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

我不能直接评论其他答案，因为我没有足够的声誉。但值得注意的是，这个问题本质上只会出现，因为从历史上看，很多dbm在处理连接时都非常糟糕（MySQL是一个特别值得注意的例子）。因此，n+1通常比join快得多。然后有一些方法可以改进n+1，但仍然不需要连接，这就是最初的问题所在。

然而，在连接方面，MySQL现在比过去好了很多。当我第一次学习MySQL时，我经常使用联接。然后我发现它们有多慢，并在代码中改用n+1。但是，最近，我又回到了连接，因为MySQL现在在处理它们方面比我刚开始使用它时要好得多。

现在，从性能角度来看，在一组索引正确的表上进行简单联接很少有问题。如果它确实影响了性能，那么使用索引提示通常可以解决这些问题。

MySQL的一个开发团队在这里讨论了这一点：

http://jorgenloland.blogspot.co.uk/2013/02/dbt-3-q3-6-x-performance-in-mysql-5610.html

所以总结是：如果您过去一直在避免连接，因为MySQL的性能糟糕，那么请在最新版本上重试。你可能会感到惊喜。