Hoe repareer je N+1 queries en optimaliseer je Eloquent?

Question

Accepted Answer

Het **N+1 query probleem** — waarbij het benaderen van relaties in een loop een aparte query per record triggert — is het meest voorkomende Eloquent prestatiesprobleem. **Eager loading** met `with()` is de primaire oplossing, samen met andere optimalisaties (kolommen selecteren, chunking, indexering).

## The N+1 problem and its fix

```php
// ❌ N+1: 1 query for posts + 1 query PER post to load its author
$posts = Post::all();                         // 1 query
foreach ($posts as $post) {
    echo $post->author->name;                  // +1 query EACH → 100 posts = 101 queries!
}

// ✅ eager load with with() → 2 queries total (posts + all authors)
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name;                  // no extra queries — authors prefetched
}
```

**`with()`** laadt relaties vooraf (één extra query per relatie in plaats van één per record), waardoor 101 queries worden omgezet in 2 — een dramatische verbetering. Dit is de essentiële Eloquent optimalisatie.

## Eager loading variations

```php
Post::with(['author', 'comments'])->get();        // multiple relationships
Post::with('comments.user')->get();                // nested
Post::with(['comments' => fn($q) => $q->latest()])->get();   // constrained
User::withCount('posts')->get();                   // count without loading (post_count)
```

## Catching N+1 automatically

```php
// in development, make lazy loading THROW so you catch N+1 problems early
Model::preventLazyLoading();    // in a service provider (dev)
// or use Laravel Debugbar / Telescope to see query counts per request
```

Tools zoals **Debugbar/Telescope** tonen querycounts per pagina (spot N+1 visueel), en `preventLazyLoading()` zet accidentele lazy loads om in errors tijdens development.

## Other Eloquent optimizations

```php
User::select('id', 'name')->get();             // fetch only needed columns
User::chunk(1000, fn($users) => ...);           // process huge sets in batches (memory)
User::cursor();                                  // lazy iteration — constant memory
// + add database INDEXES on filtered/joined columns (the biggest DB-level win)
// + use the query builder / database aggregation instead of PHP loops over collections
```

## Waarom het belangrijk is

Het repareren van N+1 queries en het optimaliseren van Eloquent is cruciale prestatieskennis voor Laravel-applicaties — het **N+1 query probleem is het enkele meest voorkomende en impactvolle prestatie probleem** in Laravel, en het begrijpen hoe dit te voorkomen is essentieel.

Het probleem is insidious omdat Eloquent's handige relatietoegang (`$post->author`) stiekem een databasequery triggert elke keer, dus code die prima werkt met weinig data degradeert catastrofaal naarmate de data groeit (100 records worden 101 queries), vaak alleen ontdekt in productie onder belasting. **Eager loading met `with()`** is de essentiële oplossing — relaties vooraf laden in een paar queries in plaats van één per record — en het kennen van de variaties (meerdere, geneste, constrained eager loads, `withCount`) dekt de gebruikelijke behoeften.

Evenredig waardevol is het weten hoe je **N+1 problemen opvangt** (Debugbar/Telescope om querycounts te zien, `preventLazyLoading()` om accidentele lazy loads in development in errors om te zetten), zodat je ze vindt vóórdat ze naar productie gaan.

Buiten N+1, andere optimalisaties — alleen benodigde kolommen selecteren, **chunking/cursors** voor het verwerken van grote datasets zonder geheugen uit te putten, databaseaggregatie boven PHP-kant collectie verwerking, en cruciaal **indexering** van gefilterde/joined kolommen (vaak de grootste win op databaseniveau) — vullen de toolkit aan.

Het begrijpen van deze — vooral het herkennen en repareren van N+1 met eager loading — is belangrijke senior-level kennis die developers onderscheidt die performante Laravel applicaties schrijven van degenen wiens apps vertragen naarmate de data groeit, waardoor het een frequent relevant, high-value onderwerp is voor het bouwen van applicaties die schalen.