@BatchSize en smart eller dum brug?

Ja, @BatchSize er beregnet til at blive brugt med dovne associationer.
Hibernate vil alligevel udføre flere sætninger i de fleste situationer, selvom antallet af ikke-initialiserede proxyer/samlinger er mindre end den angivne batchstørrelse. Se dette svar for flere detaljer. Desuden kan flere lettere forespørgsler sammenlignet med mindre større bidrage positivt til systemets samlede gennemløb.
@BatchSize på klasseniveau betyder, at den angivne batchstørrelse for enheden vil blive anvendt for alle @*ToOne dovne associationer til den enhed. Se eksemplet med Person enhed i dokumentationen.

De linkede spørgsmål/svar, du har givet, er mere bekymrede over behovet for optimering og doven indlæsning generelt. De gælder selvfølgelig også her, men de er ikke kun relateret til batchloading, hvilket blot er en af de mulige tilgange.

En anden vigtig ting relaterer sig til ivrig læsning, som er nævnt i de linkede svar, og som antyder, at hvis en ejendom altid bruges, så kan du få bedre ydeevne ved at bruge ivrig læsning. Dette er generelt ikke sandt til indsamlinger og i mange situationer for to-one foreninger heller.

Antag for eksempel, at du har følgende entitet, for hvilken bs og cs er altid bruges når A bruges.

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

  @OneToMany
  private Collection<C> cs;
}

Indlæser ivrigt bs og cs lider tydeligvis af N+1 vælger-problem, hvis du ikke slutter dig til dem i en enkelt forespørgsel. Men hvis du slutter dig til dem i en enkelt forespørgsel, for eksempel som:

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

så opretter du fuldt kartesisk produkt mellem bs og cs og returnerer count(a.bs) x count(a.cs) rækker i resultatsættet for hver a som læses én efter én og samles til entiteterne A og deres samlinger af bs og cs .

Batchhentning ville være meget optimal i denne situation, fordi du først ville læse A s, derefter bs og derefter cs , hvilket resulterer i flere forespørgsler, men med meget mindre samlet mængde data, der overføres fra databasen. Desuden er de separate forespørgsler meget enklere end en stor med joinforbindelser og er nemmere for databasen at udføre og optimere.