Performance Optimization

Since the first lesson, the same flaw keeps coming back: a list loaded in one query, then one query per item to fill in the missing data. Fifty orders displayed, one hundred and one queries issued. The Java code is flawless, the annotations are straight from the documentation, the tests pass. And the page takes eight seconds to render in production.

This chapter is the payoff. It starts with diagnosis, because you can't fix what you don't measure, and because intuition is systematically wrong here: the expensive query is almost never the one you suspect. It then presents the three tools that solve N+1 — JOIN FETCH, @EntityGraph, @BatchSize — along with the criterion for choosing between them, because they are not interchangeable and each has a hard limit.

Next comes the case that JOIN FETCH cannot handle: pagination over a fetched collection. It is a specific, silent trap that loads the entire table into memory while a discreet warning scrolls by in the logs.

The lesson ends with what no annotation can replace: PostgreSQL indexes, which schema generation does not create, and without which all the previous optimizations amount to a sequential table scan.