Catching the "N+1 query" bug that silently slows down Java applications

What is it about?

Most Java apps don't write SQL directly — frameworks like Hibernate or Spring Data JPA generate it. That convenience hides a common bug: fetching a list of orders correctly in one query, then firing one more query per order to get its details. It's called the N+1 query problem, and it's one of the most common causes of slow database-backed applications. Existing tools either just log queries without judging whether they're a problem, or only catch this inside unit tests, tied to one specific ORM, and often misfire on normal patterns like paginated lists or polling. Query Analyzer instead watches queries at the JDBC driver level, so the same detector works across Hibernate, Spring Data JPA, MyBatis, jOOQ, or raw JDBC — and it runs both in tests, as a JUnit check that fails a build before the bug ships, and in a live app, as a per-endpoint report. It scores each case by confidence rather than a raw count, so pagination, polling, and batched reads don't get flagged by mistake. Added to the unmodified Spring PetClinic sample app with one dependency and no code changes, it found three real N+1 bugs and raised no false alarms on the legitimate repeated queries on those same pages; applying its own suggested fix removed all three. On a controlled test suite it told true N+1s apart from look-alikes with no errors at all, where a simple repeated-query counter and an existing open-source detector both got it wrong.

Featured Image

Photo by Mika Baumeister on Unsplash

Photo by Mika Baumeister on Unsplash

Why is it important?

Two things set this apart from prior N+1 tools. First, it works at the JDBC layer instead of hooking into one ORM, so the same detector runs unmodified across Hibernate, Spring Data JPA, MyBatis, jOOQ, and raw JDBC — existing test-time tools are Hibernate-specific and only run in tests. Second, it tells a real N+1 apart from a merely repeated query (pagination, polling, batched reads) using a confidence model instead of a raw count, which is exactly where count-based tools misfire. Dropped into an unmodified real application with a single added dependency, it found three genuine bugs with zero false positives on the same pages, and its own suggested fix removed them — that's the bar that matters for a team deciding whether to trust an automated check in CI.

Perspectives