Hibernate 休眠子选择与批取

Hibernate提供（至少）两种解决N+1查询问题的方法。一个是将FetchMode设置为Subselect，这将生成一个带有IN子句的select和一个位于该IN子句中的Subselect。另一种方法是指定BatchSize，它生成一个select，其中包含一个包含父ID的IN子句

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

因此，我的问题是：什么时候使用Hibernate的Subselect FetchMode而不是BatchSize？如果您有大量的父项（数千个），那么Subselect可能是有意义的，但是您是否还希望使用Subselect而不是BatchSize

---

编辑：我注意到在处理急切加载时两者之间存在差异。如果您有一个xToMany关联集要急切地通过subselect加载，它将生成一个subselect，就像它是懒惰的一样。但是，如果指定BatchSize，则生成的查询将使用外部联接而不是单独的查询。有没有办法强迫Hibernate在急切加载时使用单独的批处理查询？

我不使用subselect，因为它很难控制。在一个拥有复杂业务逻辑和庞大团队的大型系统中，很难说使用了哪些查询。Subselect可能在您确切知道执行哪个查询的特定情况下工作

批量抓取有一些很大的优势。它并不总是最快的，但通常足够快。另一方面，它非常稳定，没有任何副作用，并且对业务逻辑完全透明。我从不使用高于100的批处理值。将N+1减少到合理的查询量就足够了

我发现这很有帮助。我相信批量抓取可以应用于集合和父集合，而subselect只能应用于集合

---

对于集合的获取策略，子选择将执行一次（因为批大小实际上是无限的），而对于批获取，SQL语句可能会执行多次。

我不理解为什么子选择很难控制。你能解释一下吗？Subselect取决于之前执行的查询。此查询可能非常复杂，例如，使用大量其他表并按非索引列进行筛选。因此，很难说子查询方法是否有可能提高性能；MySQL（5.5及以下版本）在嵌套查询方面的性能非常糟糕，因为它强制使它们相互关联，并为父查询中的每一行重新评估它们。我找不到任何其他方法让Hibernate为带注释的关系生成嵌套查询，因此避免subselect将防止MySQL出现令人讨厌的意外情况。