问题标签 [select-n-plus-1]

“N+1 选择问题”通常在对象关系映射 (ORM) 讨论中被表述为一个问题，我知道这与必须对对象中看似简单的东西进行大量数据库查询有关世界。

有人对这个问题有更详细的解释吗？

Foo 有 Title。
酒吧参考 Foo。我有一个与 Bars 的集合。
我需要一个带有 Foo.Title 的集合。

如果我收集了 10 个酒吧，我将调用 db 10 次。

bar.Select(x=>x.Foo.Title)

目前（使用 NHibernate Linq，我不想放弃它）检索 Bar 集合。

我读了 Ayende对此的评价。
另一个相关的问题。
一点文档。
以及另一篇相关的博文。
也许这可以帮助？这个
呢？ 也许MultiQuery是我需要的？：/

但我仍然无法在适当的解决方案中“编译”它。

如何避免选择n+1？

我有一个看起来像这样的实体和流畅的映射。

然后我执行这样的 ICriteria 查询

使用NHProf，我可以看到它执行了这样的查询，该查询应返回所有客户详细信息和地址

它按预期返回所有记录

但是，如果我然后编写代码

我仍然遇到一个 N+1 问题，它对每个地址进行选择。我怎样才能避免这种情况？

这是我所拥有的：

而且因为我必须在 A 和另一个实体 X 之间进行没有外键的内部连接，所以我必须使用 createSqlQuery 而不是 createQuery。（显然我无法更改数据库）

所以，我所能做的就是一个不错的 2N+1 选择。（使用 fetch=EAGER 或手动，都是一样的）。

有人有什么想法吗？

编辑：使用@BatchSize 我减少了从 A 到 B 的选择数量。我现在有一个 N+2 选择。

编辑 2：我不能使用内连接（带逗号），因为数据库是旧的 DB2，并且它崩溃了。

在与同行讨论 N+1 以及不良数据库查询对性能的严重影响后，我访问了http://guides.rubyonrails.org/active_record_querying.html 。

活动记录（轨道）：

如果客户端有地址，并且我打算在遍历客户端时访问它们，Rails 提供includes了让它知道继续并将它们添加到查询中，这样一来就消除了 9 个查询。

姜戈：

https://github.com/lilspikey/django-batch-select提供批量查询支持。您是否知道其他库或技巧来实现 Rails 提供的上述功能，但不那么冗长（如在 rails 示例中，其中只有 19 个字符修复 N+1 并且非常清楚）？另外，批处理选择是否以相同的方式解决了这个问题，还是这两个不同的东西？

顺便说一句，我不是在问select_related，尽管乍一看似乎是答案。我说的是address有一个外键的情况client。

我见过一些在 Rails 中:include调用 ActiveRecord 方法时传递哈希值的例子。find但是，我还没有看到任何关于这是否可以通过关系方法实现的示例。例如，假设我有以下内容：

我看到的所有示例都显示如下代码：

但我没有看到任何显示使用关系的示例。我可以做这样的事情吗？

我一直在使用 Entity Framework Profiler 来测试我在 MVC 项目中的数据访问，并且遇到了几个页面，由于 N+1 问题，我进行的数据库查询比我需要的要多得多。

这是一个显示我的问题的简单示例：

视图循环遍历成员，然后跟随每个成员的导航属性来显示他们的地址。每个地址请求都会导致额外的数据库查询。

解决此问题的一种方法是使用 Include 来确保预先查询我需要的额外表。但是，我似乎只能在直接附加到上下文的俱乐部 ObjectSet 上执行此操作。在这种情况下，ActiveClub 属性由许多控制器共享，我并不总是想预先查询成员和地址表。

我希望能够使用类似的东西：

但是，Members 是一个 EntityCollection，它没有 Include 方法。

有没有办法强制加载成员 EntityCollection 并要求 EF 也加载他们的地址？

或者，以这种方式在实体上使用 EntityCollection 导航属性，这是一个非常糟糕的主意；当你从上下文中得到它时，你应该知道你正在加载什么？

我一直在使用一种设计模式，在使用 Entity Framework Profiler 之后似乎它可能非常愚蠢。

我已经扩展了我的实体类，使其具有作为与该实体关联的集合的过滤视图的属性。像这样：

因为我主要对没有离开俱乐部的会员感兴趣，所以这个属性非常有用并且似乎很有意义。

但是，通过运行 EF Profiler，我现在知道这通常会导致 N+1 问题。如果我遍历成员并且还想显示他们的地址，那么每个地址请求都会导致额外的数据库查询。

我从这个问题知道我问我可以将我的财产修改为：

在这种情况下，这将消除 N+1 问题，但我并不总是想要地址信息，我可能想要关注 Member 的另一个导航属性。

理想情况下，我希望能够保持我的过滤属性（如 ActiveMembers）的灵活性，并能够在事后决定要在查询中包含哪些属性。像这样：

这可能吗，还是我需要重新考虑我的过滤属性想法？

我有一个获取以下数据的声明：food-serving-name、food-name、food-brand-name 和 food-category。并且所有四个字段都在不同的表中。我正在使用这样的声明

以下是我的模型

当我执行上述语句时，我可以在日志中看到很多 SQL 语句正在执行，显然这是 N+1 问题，我想我传递了不正确的包含参数来查找方法。谁能帮我优化这个电话？

Hibernate 提供（至少）两个选项来解决 N+1 查询问题。一个是将 FetchMode 设置为 Subselect，它会生成一个带有 IN 子句的选择和一个在该 IN 子句中的子选择。另一种是指定一个 BatchSize，它生成一个带有包含父母 ID 的 IN 子句的选择。

两者都有效，但我发现 Subselect 选项经常遇到性能问题，因为对父母的查询很复杂。另一方面，对于较大的 BatchSize（例如 1000），查询的数量和这些查询的复杂性都非常小。

因此，我的问题是：你什么时候会在 BatchSize 上使用 Hibernate 的 Subselect FetchMode？如果您有大量的父条目（数千个），那么 Subselect 可能是有意义的，但是在其他情况下，您是否更喜欢 Subselect 而不是 BatchSize？

编辑：在处理急切加载时，我注意到两者之间的区别。如果您将 xToMany 关联设置为急切地加载并通过子选择，它会生成一个子选择，就像它是惰性的一样。但是，如果您指定 BatchSize，则生成的查询将使用外连接而不是单独的查询。有什么方法可以强制 Hibernate 在急切加载时使用单独的批处理查询？