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

***** 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选择问题！

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

N+1的推广

N+1问题是一个ORM特有的问题名称，它将可以在服务器上合理执行的循环移动到客户端。通用问题不是ORM特有的，您可以通过任何远程API解决。在本文中，我展示了如果您调用一个API N次而不是仅调用1次，JDBC往返是如何代价高昂的。示例中的区别在于您是否调用Oracle PL/SQL过程：

dbms_output.get_lines（调用一次，接收N个项目）dbms_output.get_line（调用N次，每次接收1项）

它们在逻辑上是等价的，但由于服务器和客户端之间的延迟，您需要在循环中添加N个延迟等待，而不是只等待一次。

ORM案例

事实上，ORM-y N+1问题甚至不是ORM特有的，您也可以通过手动运行自己的查询来实现，例如，当您在PL/SQL中执行以下操作时：

-- This loop is executed once
for parent in (select * from parent) loop

  -- This loop is executed N times
  for child in (select * from child where parent_id = parent.id) loop
    ...
  end loop;
end loop;

使用联接（在本例中）实现这一点会更好：

for rec in (
  select *
  from parent p
  join child c on c.parent_id = p.id
)
loop
  ...
end loop;

现在，循环只执行一次，并且循环的逻辑已经从客户端（PL/SQL）移动到服务器（SQL），这甚至可以以不同的方式对其进行优化，例如，通过运行哈希连接（O（N））而不是嵌套循环连接（带索引的O（N log N））

自动检测N+1个问题

如果您使用的是JDBC，可以在后台使用jOOQ作为JDBC代理来自动检测N+1问题。jOOQ的解析器规范化您的SQL查询，并缓存有关连续执行父查询和子查询的数据。如果您的查询不完全相同，但在语义上是等价的，这甚至可以起作用。

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

现在您了解了这个问题，通常可以通过在查询中执行连接获取来避免。这基本上强制获取延迟加载的对象，因此数据在一个查询中而不是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章。