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

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

在Phabricator文档中可以找到问题的简短解释：

N+1查询问题是一个常见的性能反模式。它看起来像这样：$cats=load_cats（）；foreach（$cat作为$cat）{$cats_hats=>load_hats_for_cat（$cat）；// ...}假设load_cats（）的实现归结为：从猫的位置选择*。。。..和load_hats_for_cat（$cat）的实现如下：SELECT*FROM hat WHERE catID=。。。..当代码执行时，您将发出“N+1”个查询，其中N是猫的数量：从猫的位置选择*。。。SELECT*FROM hat WHERE catID=1SELECT*FROM hat WHERE catID=2SELECT*FROM hat WHERE catID=3从帽子中选择*，其中catID=4...

解决方案：

发出一个返回100个结果的查询比发出发出100个查询，每个查询返回1个结果。

在迭代之前加载所有数据。

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

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

假设你有公司和雇员。公司有许多雇员（即雇员有一个字段COMPANY_ID）。

在某些O/R配置中，当您有一个映射的Company对象并访问其Employee对象时，O/R工具将为每个员工执行一次选择，如果您只是在直接SQL中执行操作，则可以从Company_id=XX的员工中选择*。因此，N（员工人数）加1（公司）

这就是EJB实体bean的初始版本是如何工作的。我相信像Hibernate这样的东西已经解决了这个问题，但我不太确定。大多数工具通常包含有关其映射策略的信息。

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查询，并缓存有关连续执行父查询和子查询的数据。如果您的查询不完全相同，但在语义上是等价的，这甚至可以起作用。

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

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

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