A screen backed by Hibernate takes several seconds to render. Which ORM-level mistakes do you look for first, and how do you confirm each one from evidence rather than guesswork?

## Diagnose before you fix The single most common failure in ORM performance work is guessing. Almost all Hibernate slowness reduces to one of three measurable facts about a request: 1. **Too many statements** — the ORM is chatting. 2. **Too many rows** — the ORM is hauling. 3. **One slow statement** — the database's plan is bad, and that is a query/index problem, not an ORM problem. The first thing to obtain is therefore a statement count and a row count per request. Hibernate exposes both (SQL logging, `SessionFactory` statistics, or a proxying DataSource that counts). Everything below is a pattern you recognise once you have those numbers. ## Catalog A — too many statements **Lazy association touched in a loop (1 + N).** One query returns 200 parents; the loop calls `parent.getCustomer().getName()` and fires 200 more selects. Signature: one select followed by many nearly identical selects differing only in the bound id. Fix: fetch what the use case needs in the root query (`join fetch`, entity graph) or let `@BatchSize`/`FetchMode.SUBSELECT` collapse the N into a handful of `IN` queries. **EAGER mappings.** A `@ManyToOne` left at the JPA default (`EAGER`) is fetched on *every* path, including queries that never touch it, and a JPQL query typically fires an extra select per root row to satisfy it. Signature: extra selects appear even for code that ignores the association. Fix: make everything `LAZY` and fetch explicitly. **Per-row writes.** A loop persisting or updating rows one at a time produces one round trip per row. Signature: thousands of near-identical inserts. Fix: JDBC batching, ordered inserts, or a stateless/bulk path. **Cache misses masquerading as logic.** A query cache or second-level cache that is enabled but never hits adds statements (lookup plus miss) without removing any. Signature: statistics show a hit ratio near zero. ## Catalog B — too many rows **Load-everything-then-filter.** `select e from Entity e` followed by a Java `stream().filter(...)` or `.size()`. The database returns a million rows so the application can keep twelve. Signature: one statement, enormous row count, huge heap churn. Fix: push predicates, aggregates and limits into the query. **No pagination.** A list endpoint with no `setMaxResults`. It works until the table grows. **Collection fetch join plus a page size.** Hibernate cannot apply a SQL limit to a query whose rows are multiplied by a collection join, so it reads the entire matching result set, builds all the entities, and slices in memory — logging a warning while returning perfectly correct data. Signature: correct results, latency and heap proportional to table size, and that warning in the log. **Cartesian products.** Two collection joins in one query multiply rows; with two `List` associations Hibernate refuses outright (`MultipleBagFetchException`), which is at least loud. **Entities as the API representation.** Serializing a managed entity to JSON walks its associations, so the serializer — not your code — decides the fetch plan, and it decides badly. Fix: return DTOs shaped by the endpoint. ## Catalog C — the persistence context itself A session that stays open for a long unit of work accumulates every entity it has ever loaded. Flush cost is proportional to the number of managed entities (each is dirty-checked against its load-time snapshot), memory grows without bound, and lazy loads that fire late — during rendering or serialization — never surface as errors, only as query count. Fix: short sessions per unit of work, `clear()` between batches, and handing detached data or DTOs to the layer above. ## Catalog D — caching used as a bandage An unbounded second-level cache region is a memory leak with a good reputation. Caching a write-heavy entity turns every write into an invalidation. And caching does not fix a 1 + N — it makes N lookups cheaper, not fewer. Cache reference data with an explicit size and TTL, after the fetch plan is right. ## The order I work in 1. Measure statements and rows for the slow request. 2. Kill accidental fan-out — 1 + N and EAGER graphs — by making the fetch plan explicit for that use case. 3. Bound the data — predicates, projections, pagination. 4. Fix writes — batch them, and stop the persistence context growing. 5. Only then consider caching, with bounded regions and a measured hit ratio. 6. Re-measure. If one statement is still slow, it is now a database question: `EXPLAIN`, indexes, statistics. ## Why the order matters Steps 2–4 remove work. Step 5 only makes existing work cheaper, and it does so at the price of memory, staleness and invalidation complexity. Teams that reverse the order end up with a fragile cache in front of a query that should never have been issued.