Performance Tips (The N+1 Problem)

Introduction

The N+1 problem is the single most common Hibernate performance issue, and it is a direct consequence of two features you already learned: lazy fetching and how associations are loaded. This lesson shows exactly how it happens, how to catch it before it reaches production, and the standard ways to fix it.

What Is the N+1 Problem?

It happens when you run one query to fetch a list of N entities, and then, because an association on each of them is lazily loaded, Hibernate runs one additional query per entity to fetch that association — N extra queries on top of the original 1, hence "N+1".

@Entity
public class Department {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "department", fetch = FetchType.LAZY)
    private List<Employee> employees = new ArrayList<>();

    // Getters and setters
}

List<Department> departments = session
    .createQuery("FROM Department", Department.class)
    .getResultList();

for (Department dept : departments) {
    System.out.println(dept.getName() + ": " + dept.getEmployees().size() + " employees");
}

Spotting It in the Logs

With SQL logging enabled (from the previous lesson), the N+1 problem is unmistakable: one initial query, followed by a burst of near-identical queries — one per row.

Fix 1: JOIN FETCH

The most direct fix is to eagerly fetch the association in the same query, using HQL's JOIN FETCH, so Hibernate retrieves departments and their employees in a single round trip.

List<Department> departments = session.createQuery(
    "SELECT DISTINCT d FROM Department d JOIN FETCH d.employees", Department.class)
    .getResultList();

for (Department dept : departments) {
    System.out.println(dept.getName() + ": " + dept.getEmployees().size() + " employees");
}

One query instead of N+1. The DISTINCT keyword matters here — without it, a department with three employees would appear three times in the result list, once per joined row.

Fix 2: Entity Graphs

When you are using the standard JPA EntityManager (common in Spring applications), an @NamedEntityGraph describes which associations to fetch eagerly for a specific query, without changing the entity's default fetch type globally.

import javax.persistence.*;

@Entity
@NamedEntityGraph(
    name = "Department.withEmployees",
    attributeNodes = @NamedAttributeNode("employees")
)
public class Department {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "department", fetch = FetchType.LAZY)
    private List<Employee> employees = new ArrayList<>();
}

EntityGraph<?> graph = entityManager.getEntityGraph("Department.withEmployees");

List<Department> departments = entityManager.createQuery(
        "SELECT d FROM Department d", Department.class)
    .setHint("javax.persistence.fetchgraph", graph)
    .getResultList();

Fix 3: Batch Fetching

When eagerly joining is not appropriate — for example, when several different collections would need joining and that would multiply row counts badly — batch fetching reduces N+1 to a small, fixed number of queries instead of eliminating extra queries entirely.

@Entity
public class Department {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    @OneToMany(mappedBy = "department", fetch = FetchType.LAZY)
    @org.hibernate.annotations.BatchSize(size = 10)
    private List<Employee> employees = new ArrayList<>();
}

Instead of 30 individual queries, batching groups the lazy loads into 3 IN-clause queries of 10 ids each — a large reduction with no change to how the code that reads employees is written.

Choosing a Fix

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

The N+1 problem is the direct cost of lazy loading used carelessly in a loop. Once you know to look for the pattern in your SQL logs — one query, then a burst of repeats — JOIN FETCH, entity graphs, and batch fetching give you three targeted ways to collapse it back down to a small, predictable number of queries.