@BatchSize是聪明还是愚蠢的使用？

谢英光

2023-03-14

问题内容：

首先，我将解释如何理解和使用@BatchSize： @BatchSize是为了批量加载对象的关系，从而减少对数据库的SQL请求。这对
LAZY @OneToMany关系特别有用。

但是，它在 LAZY
@OneToOne关系上甚@ManyToOne至还很有用：如果从数据库中加载实体列表并要求加载懒惰的@*ToOne实体，即使我只是使用测试来加载第一个实体的关系，它也会按批加载实体名单。

请注意是否有人要测试：仅显示是否尚未加载实体：例如，如果您有一个具有经理的用户列表并列出了所有用户，则当您访问经理时，由于已存在该实体，因此不会触发任何请求已加载。

我在该方法上看到的唯一缺点是，如果从数据库加载项目列表，但仅使用其中的一部分。这是一个后过滤操作。

因此，让我们进入重点。

假设我使一切都变得好起来，即使从未使我执行本机SQL查询或将DTO对象用于多选条件查询等等，也从不进行类似于过滤后的操作。

@BatchSize在仔细考虑了使用急切的加载/连接并最终选择一个惰性关系之后，我是否可以考虑到每个惰性关系？
我是否有兴趣为寻求适当的价值，@BatchSize或者我可以认为“越大越好”？这意味着“在“ IN” SQL运算符中是否存在数量上的限制，这会使我的请求变得足够慢，以至于不再值得了？我使用Postgres，但如果您对其他SGBD的回答也感兴趣，我也有兴趣。
可选问题：似乎@BatchSize在类上使用不会产生很多结果。我仍然必须注释每一个懒惰的关系，我是否想念它还是没用？

编辑：我3的要点是我得到了不同的行为。

假设我正在加载类“ A”的实体的列表，该类与B具有LAZY OneToMany关系。现在，我要打印B的所有creationDate。因此，我正在执行经典的2
for循环。

我现在用BatchSize注释了B：

@OneToMany没有批处理批注：每组B均在每次迭代中独立加载而无需批处理。因此，我对B类的注释似乎被完全忽略了。即使我将值设置为“两个”并且我在一组中有6个条目，我也对该组有一个查询。
- @OneToMany带有注释：我具有已加载批次的特定查询。如果我将批次大小固定为两个，并且我总共有10个B帐户，那么我只会收到5个请求：无论我有多少A。如果我将其设置为100：我有1个查询B对象。

PS：我不考虑对B的任何相关查询，而这些查询可能会触发通过读取选择/子选择加载B字段。

编辑2：我才发现这篇文章为什么我不会在每个延迟加载的关系上使用@BatchSize？尽管我在张贴问题之前用Google搜索并搜索了SO，但猜想我没有使用正确的词…

但是我添加了一些不同的东西，可能会导致一个不同的答案：当我想知道在每个关系上使用BatchSize时，是在选择是否要通过加载/选择获取一个渴望的加载，或者是否要进行延迟加载。

问题答案：

是的，@BatchSize旨在与惰性关联一起使用。
即使未初始化的代理/集合的数量小于指定的批处理大小，Hibernate仍将在大多数情况下执行多个语句。此外，与较小的查询相比，较小的查询可以对系统的整体吞吐量产生积极的影响。
@BatchSize在类级别上，表示实体的指定批处理大小将应用于@*ToOne与该实体的所有惰性关联。请参阅文档中有关Person实体的示例。

您提供的链接问题/答案通常更关心优化和延迟加载的需求。它们当然也适用于此，但是它们不仅与批量加载有关，这只是可能的方法之一。

另一个重要的问题与链接加载中提到的预加载有关，这表明如果始终使用属性，则通过使用预加载可能会获得更好的性能。通常对于收藏夹而言 并非如此
，在许多情况下对于一对一关联也是如此。

例如，假设您具有以下实体，bs并且cs在使用时始终使用该实体A。

public class A {
  @OneToMany
  private Collection<B> bs;

  @OneToMany
  private Collection<C> cs;
}

如果您不将它们加入单个查询中，那么渴望加载bs并且cs显然会遭受N + 1选择问题。但是，如果您将它们加入单个查询中，例如：

select a from A
  left join fetch a.bs
  left join fetch a.cs

然后创建 完整的笛卡尔乘积 之间bs以及cs和返回count(a.bs) x count(a.cs)结果集行
对每个a被逐个读取并组装成的实体A和他们的收藏bs和cs。

批量抓取是非常优化在这种情况下，因为你会先看AS，然后bs，然后cs，导致更多的查询，但与从数据库转移总量少得多的数据量。而且，单独的查询比带有连接的大型查询要简单得多，并且数据库更易于执行和优化。