@BatchSize slim of dom gebruiken?

1. Ja, @BatchSize is bedoeld om te worden gebruikt met luie associaties.
2. Hibernate zal hoe dan ook meerdere instructies uitvoeren in de meeste situaties, zelfs als het aantal niet-geïnitialiseerde proxy's/verzamelingen kleiner is dan de opgegeven batchgrootte. Zie dit antwoord voor meer details. Ook kunnen meer lichtere zoekopdrachten in vergelijking met minder grotere een positieve bijdrage leveren aan de algehele verwerkingscapaciteit van het systeem.
3. @BatchSize op klasseniveau betekent dat de gespecificeerde batchgrootte voor de entiteit wordt toegepast voor alle @*ToOne luie associaties met die entiteit. Zie het voorbeeld met de Person entiteit in de documentatie.

De gekoppelde vraag/antwoorden die je hebt gegeven, zijn meer bezorgd over de noodzaak van optimalisatie en lui laden in het algemeen. Ze zijn hier natuurlijk ook van toepassing, maar ze hebben niet alleen betrekking op het laden van batches, wat slechts een van de mogelijke benaderingen is.

Een ander belangrijk ding heeft betrekking op gretig laden, dat wordt vermeld in de gekoppelde antwoorden en dat suggereert dat als een eigenschap altijd wordt gebruikt, u betere prestaties kunt krijgen door gretig laden te gebruiken. Dit is over het algemeen niet waar voor collecties en in veel situaties ook voor één-verenigingen.

Stel dat u bijvoorbeeld de volgende entiteit heeft waarvoor bs en cs zijn altijd gebruikt wanneer A wordt gebruikt.

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

  @OneToMany
  private Collection<C> cs;
}

Laadt gretig bs en cs lijdt duidelijk aan het N+1 select-probleem als u ze niet in één enkele zoekopdracht samenvoegt. Maar als u ze samenvoegt in een enkele zoekopdracht, bijvoorbeeld als:

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

dan creëer je volledig Cartesiaans product tussen bs en cs en retourneren count(a.bs) x count(a.cs) rijen in de resultatenset voor elke a die één voor één worden gelezen en samengevoegd tot de entiteiten van A en hun verzamelingen van bs en cs .

Batch ophalen zou in deze situatie zeer optimaal zijn, omdat u eerst A . zou lezen s, dan bs en dan cs , wat resulteert in meer zoekopdrachten, maar met veel minder totale hoeveelheid gegevens die uit de database wordt overgedragen. De afzonderlijke query's zijn ook veel eenvoudiger dan een grote met joins en zijn gemakkelijker uit te voeren en te optimaliseren voor de database.