What does enabling the hibernate.generate_statistics setting give you, and what kinds of numbers can you read out of Hibernate's Statistics API?

## What the setting does By default Hibernate keeps no bookkeeping about its own behaviour — that would cost something on every operation. `hibernate.generate_statistics=true` (or `Statistics.setStatisticsEnabled(true)` at runtime) switches on a `StatisticsImplementor` that Hibernate notifies as it works: each prepared statement, each entity loaded, each flush, each cache lookup. The accumulated numbers live on a single `Statistics` object owned by the `SessionFactory`. In plain JPA you get to it by unwrapping: `Statistics stats = entityManagerFactory.unwrap(SessionFactory.class).getStatistics();` ## The counters worth knowing **Statement and entity volume.** `getPrepareStatementCount()` and `getCloseStatementCount()` tell you how many JDBC statements the session factory has issued — the single most useful number for spotting a code path that fans out into per-row queries. Alongside it sit `getEntityLoadCount()`, `getEntityFetchCount()` (loads that were *not* satisfied from a cache or the persistence context), `getEntityInsertCount()`, `getEntityUpdateCount()`, `getEntityDeleteCount()`, and the collection equivalents (`getCollectionLoadCount()`, `getCollectionFetchCount()`, `getCollectionRecreateCount()`). **Queries.** `getQueryExecutionCount()` is the total; `getQueries()` returns every distinct query string seen, and `getQueryStatistics(String)` gives that query's execution count, total/average/min/max execution time and rows returned. `getQueryExecutionMaxTime()` and `getQueryExecutionMaxTimeQueryString()` name the slowest single execution since the last clear. **Caches.** Second-level cache activity is reported as hit/miss/put counts, both globally (`getSecondLevelCacheHitCount()` and friends) and per region via `getCacheRegionStatistics(regionName)`. The query cache and the natural-id cache have their own triples. The hit ratio — hits / (hits + misses) — is how you decide whether a cache region is earning its keep. Also note `getQueryCacheHitCount()` versus `getQueryCachePutCount()`: a region with many puts and few hits is pure overhead, and one with a high miss count is either mis-sized or holds data whose keys never repeat. **Sessions and connections.** `getSessionOpenCount()`, `getSessionCloseCount()`, `getConnectCount()`, `getFlushCount()`, `getTransactionCount()` and `getSuccessfulTransactionCount()`. A gap between opened and closed sessions is a leak; a gap between total and successful transactions is a rollback rate. ## Session-scoped view `session.getStatistics()` returns a `SessionStatistics` with `getEntityCount()` and `getCollectionCount()` — how many entities and collections this persistence context is currently holding. That is the direct way to catch a session that is accumulating tens of thousands of managed entities during a batch job, which is a memory and dirty-checking problem rather than a query-count problem. ## Semantics you must state correctly - Counters are **cumulative from startup** (or from the last `clear()`), not per request and not windowed. Exporting them to a monitoring system means exporting monotonic counters and letting the monitoring system rate them; the max-time fields are the exception, being stateful maxima that only reset on `clear()` and therefore misleading if you graph them raw. - They are **factory-wide**, aggregated across all threads. Concurrent requests interleave, so you cannot attribute a delta to one request unless the test is single-threaded. - They cover **Hibernate's** view of the world. Statements issued through a raw JDBC connection or a native query executed outside the session are not necessarily reflected the same way, and cache hits mean 'Hibernate did not need the database', which is precisely why the statement count can stay flat while the load count climbs. ## Cost and where it belongs The instrumentation uses concurrent counters, so it is cheap per operation but not free, and under high concurrency the shared counters are a contended write. The bigger risk is the per-query map: it keys on the query string, so an application that builds SQL by string concatenation with embedded literals can accumulate an unbounded number of `QueryStatistics` entries. With named/parameterised queries the set is bounded and the map is harmless. The pragmatic split: on permanently in test and staging, on in production only when you actually export the numbers and your queries are parameterised, and always paired with `clear()` discipline in tests so each assertion starts from zero.