正在执行的查询是：

PurchaseOrder 中的映射：

ShoppingBasket 中的映射：

当该查询被执行时，它被翻译成以下查询：

-- 以下类型的 1 个查询，检索给定状态的所有篮子和订单

-- 以下类型的 n 个查询，一个用于上一个查询的每个篮子结果，以检索关联的订单

我尝试更改获取策略（我知道无论如何使用 HQL 都会忽略它），更改获取计划以及出于绝望的“可选”属性。有没有办法让 Hibernate 在单个查询中加载带有关联 ShoppingBaskets 的 PurchaseOrders？我是否必须使用字节码检测来实现这一点，如果是，怎么做？

Hibernate调试日志如下：

在下面的代码中，我预计n+1会发生查询问题，但它没有发生。 用户.java：

电话号码.java：

用户.hbm.xml：

电话号码.hbm：

休眠.cfg：

HQLClient.java：

输出如下：

我希望每个电话号码记录到一个用户 ID 会有单独的选择语句，但是对于 3 个电话号码 - 1 个用户 ID 有一个选择语句 [而不是 (3+1)]。为什么会这样？

谢谢！

我对数据库相当缺乏经验，并且刚刚阅读了有关“n+1 选择问题”的信息。我的后续问题：假设数据库与我的程序位于同一台机器上，缓存在 RAM 中并正确索引，为什么 n+1 查询模式很慢？

作为一个例子，让我们从接受的答案中获取代码：

根据我对数据库缓存的心智模型，每个SELECT * FROM Wheel WHERE CarId = ?查询都应该需要：

• 1 次查找以到达“Wheel”表（一个 hashmap get()）
• 1 次查找以到达具有指定CarId（另一个 hashmap get()）的 k 个轮子列表
• k 查找以获取每个匹配车轮的车轮行（k 指针取消引用）

即使我们将它乘以一个小的常数因子以获得额外的开销，因为内部内存结构，它仍然应该快得不明显。进程间通信是瓶颈吗？

编辑：我刚刚通过 Hacker News 找到了这篇相关文章：通过 Postgres Internals 遵循 Select Statement。-HN讨论线程。

编辑2：为了澄清，我确实假设N很大。那么，一个不平凡的开销将增加一个明显的延迟，是的。我在问为什么对于上述设置，开销首先不是微不足道的。

我有这些课程：

当我运行此查询时：

它执行一个查询以从 InvoiceItem 中选择记录，如果我有 10000 个发票项目，它会生成 10000 个附加查询以从每个 InvoiceItem 中选择发票。

我认为如果可以在单个 sql 中获取所有记录会更好。实际上，我觉得很奇怪为什么它不是默认行为。

那么，我该怎么做呢？

我有一些对象的列表，这些对象是从数据库查询结果中填充的。

如果我需要访问此列表中需要再次查询数据库的一个/几个对象的属性，如下所示：

那么，有没有办法只有一个数据库调用来填充Persons每个Competitionin 的属性myList？

如果我的列表中有 1000 场比赛，当我遍历列表并访问 Persons 属性时，我不希望有 1000 个查询。

编辑：如果它允许更多可能性，我不介意使用 IEnumerable 而不是 List。

A:parent has_many :children我正在尝试检索父母的最大孩子的年龄作为parent. 我愿意接受任何有效地实现这一目标的解决方案。

我试图做一个子查询的原因是让数据库做n+1开销，而不是为每个父母发出单独的数据库请求。两者都是低效的，但使用子查询似乎更有效。

示例用例：

我的尝试：

这将返回所有父母的最大年龄数组；我想将其限制为只有 1 个父级，或者在检索所有父级时将其作为父级的属性包含在内。

2015-06-19 11:00 更新

这是我想出的一个可行的解决方案；有更有效的选择吗？

示例用法：

我们有以下2个课程

为了保持示例的准确性，省略了一些细节，例如其他类属性和实体注释。如果您需要更多详细信息，请告诉我。是的，从 StagingConceptDescription 到 StagingConcept 的 FK 是非 PK 外键。

当我创建一个标准时：

我在一个查询中从数据库中获取所有 StagingConcept 实体。但我需要descriptions为每个 StagingConcept 获取。为此，我编写了一个查询：

生成的 SQL 如下所示：

它确实获取了所有 StagingConcepts 及其描述，尽管该 SQL 中的结果集稍大一些。

直到这里，一切看起来都很好。但随后它又试图为每一个描述找到一个分期概念。因此，如果我有 30000 个暂存概念和 60000 个描述，它将发送另外 60000 个查询来获取每个描述的暂存概念。这看起来有点讨厌并且占用大量时间，足以超过事务超时。

为了尝试解决此问题，我将 StagingConceptDescription 更改为

因此，ManyToOne 关系现在明确设置为 LAZY。而且，该关系表明该概念不是可选的，以试图表明该关系是非可选的。通过设置它，我的意思是告诉 hibernate 如果需要，创建一个代理对象应该是可以的，因为关系的另一端总是存在的。但这一切都没有任何效果。不太确定这是否可行。

我也尝试过@Fetch注释等。它们都不起作用。即使设置为@LazyToOne(LazyToOneOption.PROXY)没有任何效果。

我有一个模型Booking，与Availability>>FacilityVenue

我的视图中有一个页面，它呈现bookings给定venue的所有内容，它导致了一个巨大的 N+1 查询。

控制器动作：

看法：

部分的：

子弹日志：

我已经包含在类变量中，我不确定我应该在哪里做。

这里提供了pht中ORM中select n+1问题的简单例子，但是思路在其他语言的其他ORM中应该是一样的。

一个典型的解决方案是使用 eager loading 将其减少到 1 个查询，我认为这不是很难，但是，OTOH，它非常脆弱，因为后面的重构需要开发人员更改两个地方，否则这个 select n + 1个问题再次出现。

我的直觉是应该可以进行一些路径分析来确定这些子属性将在代码的后面部分使用，所以让我们生成查询以一次性收集所有必要的信息。

对于使用解释语言（如 ruby​​、php 等）实现的 ORM，这可能要求太多了。但是，无论是 Java（NHibernate）还是 C#（实体框架）都没有进行这种路径分析，AFAIK。为什么是这样？

我可以使用任何工具、插件或技术来帮助识别 Django 应用程序上的 n+1 个查询吗？Rails 有一个名为 bullet 的 gem，它可以识别 n+1 个查询和日志或以多种方式弹出警告，但我无法为 Django 找到任何类似的东西。如果没有人知道现有的解决方案，我愿意接受有关如何编写自己的插件的指导。