在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问题至少有两种解决方案：

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

因为这个问题，我们离开了Django的ORM。基本上，如果你尝试

for p in person:
    print p.car.colour

ORM将很高兴地返回所有人（通常作为Person对象的实例），但随后需要为每个Person查询car表。

一种简单且非常有效的方法是我称之为“扇形折叠”的方法，它避免了来自关系数据库的查询结果应该映射回组成查询的原始表的荒谬想法。

步骤1：宽选择

  select * from people_car_colour; # this is a view or sql function

这将返回类似

  p.id | p.name | p.telno | car.id | car.type | car.colour
  -----+--------+---------+--------+----------+-----------
  2    | jones  | 2145    | 77     | ford     | red
  2    | jones  | 2145    | 1012   | toyota   | blue
  16   | ashby  | 124     | 99     | bmw      | yellow

第2步：客观化

将结果吸入通用对象创建器中，并在第三项之后添加一个要拆分的参数。这意味着“jones”对象不会被制作多次。

步骤3：渲染

for p in people:
    print p.car.colour # no more car queries

有关python的扇形折叠的实现，请参阅此网页。

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

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

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

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

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

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

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

查看Ayende关于以下主题的帖子：打击NHibernate中的选择N+1问题。

基本上，当使用像NHibernate或EntityFramework这样的ORM时，如果您有一对多（主详细信息）关系，并且希望列出每个主记录的所有详细信息，则必须对数据库进行N+1次查询调用，“N”是主记录的数量：1次查询获取所有主记录，N次查询，每个主记录一次，获取每个主记录所有详细信息。

更多数据库查询调用→ 延迟时间更长→ 降低了应用程序/数据库性能。

然而，ORM可以选择避免这个问题，主要是使用JOIN。