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

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

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

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

SELECT 
table1.*
, table2.*
INNER JOIN table2 ON table2.SomeFkId = table1.SomeId

这将获得一个结果集，其中表2中的子行通过返回表2中每个子行的表1结果而导致重复。O/R映射器应根据唯一的键字段区分表1实例，然后使用所有表2列填充子实例。

SELECT table1.*

SELECT table2.* WHERE SomeFkId = #

N+1是第一个查询填充主对象，第二个查询填充返回的每个唯一主对象的所有子对象的位置。

考虑：

class House
{
    int Id { get; set; }
    string Address { get; set; }
    Person[] Inhabitants { get; set; }
}

class Person
{
    string Name { get; set; }
    int HouseId { get; set; }
}

以及具有类似结构的表格。对地址“22 Valley St”的单个查询可能返回：

Id Address      Name HouseId
1  22 Valley St Dave 1
1  22 Valley St John 1
1  22 Valley St Mike 1

O/RM应该用ID=1，Address=“22 Valley St”填充Home的实例，然后用Dave、John和Mike的People实例填充Inhabitants数组，只需一个查询。

对上述相同地址的N+1查询将导致：

Id Address
1  22 Valley St

使用单独的查询，如

SELECT * FROM Person WHERE HouseId = 1

并产生单独的数据集，如

Name    HouseId
Dave    1
John    1
Mike    1

并且最终结果与上述单个查询相同。

单一选择的优点是您可以提前获得所有数据，这可能是您最终想要的。N+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章。

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

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

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

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

因为这个问题，我们离开了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的扇形折叠的实现，请参阅此网页。