提供的链接有一个非常简单的n+1问题示例。如果你将它应用于Hibernate，它基本上是在谈论相同的事情。查询对象时，实体将被加载，但任何关联（除非另有配置）都将被延迟加载。因此，一个查询用于根对象，另一个查询加载每个根对象的关联。返回的100个对象意味着一个初始查询，然后是100个附加查询，以获得每个对象的关联，n+1。

http://pramatr.com/2009/02/05/sql-n-1-selects-explained/

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

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的优点是减少了查询复杂性，并且可以使用延迟加载，其中子结果集仅在第一次请求时加载。

我不能直接评论其他答案，因为我没有足够的声誉。但值得注意的是，这个问题本质上只会出现，因为从历史上看，很多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的性能糟糕，那么请在最新版本上重试。你可能会感到惊喜。

正如其他人更优雅地指出的那样，问题是您要么拥有OneToMany列的笛卡尔积，要么正在进行N+1选择。无论是可能的巨大结果集，还是与数据库的聊天。

我很惊讶没有提到这一点，但我是如何解决这个问题的。。。我制作了一个半临时ID表。当您有IN（）条款限制时，我也会这样做。

这并不适用于所有情况（可能甚至不适用于大多数情况），但如果您有很多子对象，使得笛卡儿乘积无法控制（即大量的OneToMany列，结果的数量将是列的乘积），并且它更像是一个批处理作业，那么它就特别适用。

首先，将父对象ID作为批处理插入到ID表中。batch_id是我们在应用程序中生成并保存的东西。

INSERT INTO temp_ids 
    (product_id, batch_id)
    (SELECT p.product_id, ? 
    FROM product p ORDER BY p.product_id
    LIMIT ? OFFSET ?);

现在，对于每个OneToMany列，您只需在id表INNER上执行SELECT，然后使用WHERE batch_id=（反之亦然）将子表JOIN。您只需要确保按id列排序，因为这将使合并结果列更容易（否则，您将需要一个HashMap/Table用于整个结果集，这可能不会那么糟糕）。

然后，只需定期清理ids表。

如果用户选择例如100个左右不同的项目进行某种批量处理，这也特别有效。将100个不同的ID放入临时表中。

现在，您正在执行的查询数量是OneToMany列的数量。