“N+1选择问题”在对象关系映射（ORM）讨论中通常被称为一个问题，我理解这与必须为对象世界中看似简单的东西进行大量数据库查询有关。
有人对这个问题有更详细的解释吗？
当前回答
假设你有公司和雇员。公司有许多雇员（即雇员有一个字段COMPANY_ID）。
在某些O/R配置中，当您有一个映射的Company对象并访问其Employee对象时，O/R工具将为每个员工执行一次选择，如果您只是在直接SQL中执行操作，则可以从Company_id=XX的员工中选择*。因此，N（员工人数）加1（公司）
这就是EJB实体bean的初始版本是如何工作的。我相信像Hibernate这样的东西已经解决了这个问题，但我不太确定。大多数工具通常包含有关其映射策略的信息。
其他回答
正如其他人更优雅地指出的那样，问题是您要么拥有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列的数量。
假设你有公司和雇员。公司有许多雇员（即雇员有一个字段COMPANY_ID）。
在某些O/R配置中，当您有一个映射的Company对象并访问其Employee对象时，O/R工具将为每个员工执行一次选择，如果您只是在直接SQL中执行操作，则可以从Company_id=XX的员工中选择*。因此，N（员工人数）加1（公司）
这就是EJB实体bean的初始版本是如何工作的。我相信像Hibernate这样的东西已经解决了这个问题，但我不太确定。大多数工具通常包含有关其映射策略的信息。
查看Ayende关于以下主题的帖子：打击NHibernate中的选择N+1问题。
基本上，当使用像NHibernate或EntityFramework这样的ORM时，如果您有一对多（主详细信息）关系，并且希望列出每个主记录的所有详细信息，则必须对数据库进行N+1次查询调用，“N”是主记录的数量：1次查询获取所有主记录，N次查询，每个主记录一次，获取每个主记录所有详细信息。
更多数据库查询调用→ 延迟时间更长→ 降低了应用程序/数据库性能。
然而，ORM可以选择避免这个问题，主要是使用JOIN。
假设您有一组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章。
提供的链接有一个非常简单的n+1问题示例。如果你将它应用于Hibernate，它基本上是在谈论相同的事情。查询对象时，实体将被加载，但任何关联（除非另有配置）都将被延迟加载。因此，一个查询用于根对象，另一个查询加载每个根对象的关联。返回的100个对象意味着一个初始查询，然后是100个附加查询，以获得每个对象的关联，n+1。
http://pramatr.com/2009/02/05/sql-n-1-selects-explained/
