在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个结果。

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

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

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

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

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

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

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

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

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

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

在我看来，《Hibernate陷阱：为什么关系应该懒惰》中的文章与真正的N+1问题完全相反。

如果您需要正确的解释，请参阅Hibernate-第19章：提高性能-获取策略

选择提取（默认值）为极易受到N+1选择的影响问题，因此我们可能希望启用联接获取

假设你有公司和雇员。公司有许多雇员（即雇员有一个字段COMPANY_ID）。

在某些O/R配置中，当您有一个映射的Company对象并访问其Employee对象时，O/R工具将为每个员工执行一次选择，如果您只是在直接SQL中执行操作，则可以从Company_id=XX的员工中选择*。因此，N（员工人数）加1（公司）

这就是EJB实体bean的初始版本是如何工作的。我相信像Hibernate这样的东西已经解决了这个问题，但我不太确定。大多数工具通常包含有关其映射策略的信息。