default_batch_fetch_size推荐值

Question

我正在学习一些hibernate教程，却被默认的批处理大小卡住了。阅读专家关于“Hibernate能否用于性能敏感的应用程序”的评论清楚地解释了重要性，但我试图理解为什么链接中使用了建议值4、8、16或32。

问候塔伦

Answer 1

关于内存/启动时间问题。试试：

 <property name="hibernate.batch_fetch_style" value="dynamic" />

只有一条准备好的语句带有“where id=？”，但是，会话中相同类型的实体的批量获取是在hibernate的限制下动态构造的。默认的批处理大小。

Answer 2

我们正在使用hibernate。生产中的默认批处理提取大小=100。因此，在某些情况下，我们有3个查询，而不是300个，所以这对我们的数据库来说是一个很好的性能提升。

Answer 3

总结：

启用批处理获取时，Hibernate会准备大量查询：这些查询会占用大量无法篡改的内存。1000的批处理大小需要大约150 Mo的RAM。

所以，使用较低的常规批处理大小（如10、20或40）是最好的，只需为带有@BatchSize注释的特定集合设置较大的批处理大小。

细节：

这里解释了获取批次大小，理解了Hibernate中的@BatchSize，“Hibernate.default_batch_fetch_size”是通用参数，“@BatchSize”注释允许覆盖特定关联的通用参数。

但是这些解释并没有真正回答“为什么官方文档推荐值4、8或16”的问题？显然，现代数据库可以处理IN子句中远远超过16个值的查询，并且在IN子句中使用假设1000个值进行查询将允许执行更少的查询，从而具有更好的性能...那么为什么不将1000设置为批处理大小呢？

我做到了，我把1024作为批处理大小，答案很快就出现了：tomcat服务器需要更多的时间来启动，在调试日志中，我可以看到很多带有“静态选择实体......”的行。

Hibernate准备了数千个静态查询，下面是实体的部分日志：

...
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?, ?, ?, ?, ?, ?, ?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?, ?, ?, ?, ?, ?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?, ?, ?, ?, ?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?, ?, ?, ?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?, ?, ?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?, ?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id in (?, ?)
Static select for entity Profile [PESSIMISTIC_READ]: select xxx_ with (holdlock, rowlock ) where id = ?
...

如您所见，Hibernate准备批处理获取请求，但不是为所有请求。Hibernate为1,2,3…准备所有html" target="_blank">请求。。。。10个参数，然后只准备参数数等于batchSize/（2^n）的请求。例如，如果batchSize=120=

因此，我尝试对一个包含不同数量元素的集合进行批量提取，结果如下：

>

对于获取18个项目，hibernate进行了2次查询：一次有16个项目，一次有2个项目。

为了获取16项，hibernate使用16项进行了1次查询。

为了获取12个项目，hibernate进行了两次查询：一次是10个项目，另一次是2个项目。

Hibernate仅使用启动时准备的语句。

之后，我监控了所有这些准备好的语句的RAM使用情况：

>

批处理大小=0=

批次大小=32=

batchSize=64=

批量大小=1000=

（我的项目是中型的，大约300个实体）

现在是得出结论的时候了：

1） batchsize对启动时间和内存消耗有很大影响。它不会随batchsize线性扩展，batchsize为80的成本是batchsize为10的成本的2倍。

2）Hibernate无法检索具有任何大小批处理的项目的集合，它只使用准备好的批处理查询。如果您设置batchSize=120，准备好的查询将是具有120, 60, 30, 15, 10, 9, 8, 7, 6, 5, 4, 3, 2和1参数的查询。因此，如果您尝试获取包含220个项目的集合，将触发4个查询：第一个将检索120个项目，第二个60个，第三个30个，第四个10个。

这就解释了为什么推荐的批量较小。我建议设置一个较低的全局batchSize，比如20（在我看来，20似乎比16好，因为它不会生成比16更多的准备好的查询），并仅在需要时设置一个更大的@batchSize。

（我使用了Hibernate 5.1）