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

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

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

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

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

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

我不能直接评论其他答案，因为我没有足够的声誉。但值得注意的是，这个问题本质上只会出现，因为从历史上看，很多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选择问题是一个难题，在单元测试中检测这种情况是有意义的。我已经开发了一个小型库，用于验证给定测试方法或任意代码块执行的查询数量-JDBC Sniffer

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

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

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

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

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