@BatchSize inteligentne czy głupie zastosowanie?

1. Tak, @BatchSize ma być używany z leniwymi skojarzeniami.
2. Hibernacja i tak wykona wiele instrukcji w większości sytuacji, nawet jeśli liczba niezainicjowanych serwerów proxy/kolekcji jest mniejsza niż określony rozmiar wsadu. Zobacz tę odpowiedź, aby uzyskać więcej informacji. Ponadto, więcej lżejszych zapytań w porównaniu z mniejszymi, może pozytywnie wpłynąć na ogólną przepustowość systemu.
3. @BatchSize na poziomie klasy oznacza, że ​​określony rozmiar partii dla encji zostanie zastosowany dla wszystkich @*ToOne leniwe skojarzenia z tym podmiotem. Zobacz przykład z Person podmiot w dokumentacji.

Połączone pytania/odpowiedzi, które podałeś, są bardziej zaniepokojone potrzebą optymalizacji i ogólnie leniwym ładowaniem. Oczywiście mają one zastosowanie również tutaj, ale nie są związane tylko z ładowaniem wsadowym, co jest tylko jednym z możliwych podejść.

Kolejna ważna rzecz dotyczy żarliwego ładowania, o którym mowa w powiązanych odpowiedziach i które sugeruje, że jeśli właściwość jest zawsze używana, można uzyskać lepszą wydajność przy użyciu żarliwego ładowania. To generalnie nieprawda dla kolekcji, a także w wielu sytuacjach dla stowarzyszeń indywidualnych.

Załóżmy na przykład, że masz następującą encję, dla której bs i cs są zawsze używane, gdy A jest używany.

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

  @OneToMany
  private Collection<C> cs;
}

Gorące ładowanie bs i cs oczywiście cierpi na problem wyboru N+1, jeśli nie połączysz ich w jednym zapytaniu. Ale jeśli dołączysz do nich w jednym zapytaniu, na przykład:

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

następnie tworzysz pełny produkt kartezjański między bs i cs i zwrócenie count(a.bs) x count(a.cs) wiersze w zestawie wyników dla każdego a które są odczytywane jeden po drugim i składane w jednostki A i ich kolekcje bs i cs .

Pobieranie wsadowe byłoby w tej sytuacji bardzo optymalne, ponieważ najpierw przeczytałbyś A s, potem bs a następnie cs , co skutkuje większą liczbą zapytań, ale znacznie mniejszą całkowitą ilością danych przesyłanych z bazy danych. Ponadto oddzielne zapytania są znacznie prostsze niż duże z łączeniami i są łatwiejsze do wykonania i optymalizacji dla bazy danych.