@BatchSize умна или глупава употреба?

1. Да, @BatchSize е предназначено да се използва с мързеливи асоциации.
2. Hibernate така или иначе ще изпълни множество оператори в повечето ситуации, дори ако броят на неинициализираните прокси сървъри/колекции е по-малък от посочения размер на пакета. Вижте този отговор за повече подробности. Освен това по-леките заявки в сравнение с по-малко по-големите могат да допринесат положително за общата пропускателна способност на системата.
3. @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 .

Пакетното извличане би било много оптимално в тази ситуация, защото първо ще прочетете A s, след това bs и след това cs , което води до повече заявки, но с много по-малко общо количество данни, които се прехвърлят от базата данни. Освен това отделните заявки са много по-прости от една голяма с обединения и са по-лесни за изпълнение и оптимизиране от базата данни.