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

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

与产品有一对多关系的供应商。一个供应商拥有（供应）许多产品。

***** Table: Supplier *****
+-----+-------------------+
| ID  |       NAME        |
+-----+-------------------+
|  1  |  Supplier Name 1  |
|  2  |  Supplier Name 2  |
|  3  |  Supplier Name 3  |
|  4  |  Supplier Name 4  |
+-----+-------------------+

***** Table: Product *****
+-----+-----------+--------------------+-------+------------+
| ID  |   NAME    |     DESCRIPTION    | PRICE | SUPPLIERID |
+-----+-----------+--------------------+-------+------------+
|1    | Product 1 | Name for Product 1 |  2.0  |     1      |
|2    | Product 2 | Name for Product 2 | 22.0  |     1      |
|3    | Product 3 | Name for Product 3 | 30.0  |     2      |
|4    | Product 4 | Name for Product 4 |  7.0  |     3      |
+-----+-----------+--------------------+-------+------------+

因素：

供应商的懒惰模式设置为“true”（默认）用于查询产品的获取模式为Select获取模式（默认）：访问供应商信息缓存第一次不起作用访问供应商

提取模式为选择提取（默认）

// It takes Select fetch mode as a default
Query query = session.createQuery( "from Product p");
List list = query.list();
// Supplier is being accessed
displayProductsListWithSupplierName(results);

select ... various field names ... from PRODUCT
select ... various field names ... from SUPPLIER where SUPPLIER.id=?
select ... various field names ... from SUPPLIER where SUPPLIER.id=?
select ... various field names ... from SUPPLIER where SUPPLIER.id=?

结果：

1个产品选择语句供应商的N个选择语句

这是N+1选择问题！

正如其他人更优雅地指出的那样，问题是您要么拥有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列的数量。

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

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

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

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

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

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

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