How do you confirm and quantify that a running Java application is issuing one database query per returned row — what do you switch on or instrument, and what specifically do you measure?

## Reframe the measurement The defining property of an N+1 is not slowness of any statement but **count proportional to result size**. So every technique below serves one of two purposes: *see the pattern*, or *count per operation and watch it scale*. A useful mental protocol: 1. Pick one logical operation (an endpoint, a job step, a service method). 2. Count statements executed while it runs. 3. Repeat with 10x the data. 4. If the count moved roughly 10x, you have your answer. ## Level 1 — SQL logging (development) Enable the logger `org.hibernate.SQL` at DEBUG to see each statement, and `org.hibernate.orm.jdbc.bind` (older: `org.hibernate.type.descriptor.sql.BasicBinder`) at TRACE for bound parameters. Prefer this over the `hibernate.show_sql` property, which writes to stdout with no logging control. The visual signature is unmistakable: one query with a `where`/`join`, then a run of identical `select ... where id=?` lines. The position of the burst tells you the cause — immediately after the main query means an eagerly-mapped association; interleaved with your own log lines means a lazy association dereferenced in a loop. Limitations: it does not count for you, it does not attribute statements to a request, and it is far too verbose for production. ## Level 2 — Hibernate Statistics Set `hibernate.generate_statistics=true` and read `SessionFactory.getStatistics()`: - `getPrepareStatementCount()` — total statements prepared; the number closest to "round trips". - `getQueryExecutionCount()` — HQL/JPQL/Criteria executions. - `getEntityLoadCount()` / `getEntityFetchCount()` — the second is specifically loads that were *not* part of an explicit query, i.e. exactly the secondary selects of an N+1. - `getCollectionFetchCount()` versus `getCollectionLoadCount()` — same distinction for collections. The pair `entityFetchCount` and `collectionFetchCount` are the sharpest indicators you have inside Hibernate: a large fetch count relative to query count means data is being pulled in outside your queries. Additionally, `hibernate.session.events.log=true` (and the slow-session threshold setting) makes Hibernate log a per-session summary — statements prepared, time in JDBC — which converts to "statements per request" directly. Statistics carry a small overhead; running them permanently in production is usually acceptable and often worth it, but validate that. ## Level 3 — DataSource proxies and assertions Wrapping the `DataSource` with **datasource-proxy** or **p6spy** gives ORM-independent counting and a hook to act on: - count statements in a request scope and log or emit a metric when a threshold is exceeded; - in tests, assert a hard budget: this operation must execute at most 3 statements. Libraries such as QuickPerf exist for this, but a few dozen lines around datasource-proxy is enough. This is the technique that turns detection into **prevention**, because it is the only one that can fail a build. ## Level 4 — outside the process - **APM / distributed tracing.** A trace of a request with 200 database spans is self-diagnosing, and span counts per endpoint make a good dashboard and alert. - **Database-side statement statistics.** `pg_stat_statements` on PostgreSQL and the performance schema on MySQL rank statements by *call count* as well as by time. A primary-key select with tens of millions of calls and a microsecond mean is an N+1 pointing straight at the table involved. - **Connection-pool metrics.** Rising checkout duration without rising database CPU is the classic macroscopic symptom. ## Reading the numbers correctly - **Distinct ids, not rows.** The persistence context deduplicates, so a result set with repeated parents produces fewer statements. Never conclude "no N+1" from a fixture with low cardinality. - **Caching hides it.** A warm second-level cache suppresses statements; measure cold, or clear the cache first. - **Batching changes the shape, not the class of problem.** With batch fetching enabled you see `where id in (?, ?, ?, ...)` — statement count falls to N/size + 1, still proportional to N. - **Attribute to a boundary.** A raw statement count is useless without knowing which operation produced it, so scope the counter to a request/transaction. ## What a strong answer sounds like Name the metric (statements per operation), name at least two mechanisms (Hibernate Statistics counts and a DataSource-level counter), give the scaling test, and finish with the point that detection should be automated in tests so the defect cannot re-enter — not left to someone reading logs.