Hvordan løser du N+1-forespørgsler og optimerer Eloquent?

Question

Accepted Answer

**N+1-forespørgselproblemet** — hvor adgang til relationer i en løkke udløser en separat forespørgsel pr. post — er det mest almindelige Eloquent-ydelsesspørgsmål. **Eager loading** med `with()` er den primære løsning, sammen med andre optimiseringer (valg af kolonner, chunking, indeksering).

## N+1-problemet og dets løsning

```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()`** eager-loader relationer på forhånd (én ekstra forespørgsel pr. relation i stedet for én pr. post), hvilket gør 101 forespørgsler til 2 — en dramatisk forbedring. Dette er den essentielle Eloquent-optimisering.

## Variationer af eager loading

```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)
```

## Automatisk fangst af N+1

```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
```

Værktøjer som **Debugbar/Telescope** viser forespørgselsantal pr. side (se N+1 visuelt), og `preventLazyLoading()` gør utilsigtede lazy loads til fejl under udvikling.

## Andre Eloquent-optimiseringer

```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
```

## Hvorfor det betyder noget

At løse N+1-forespørgsler og optimere Eloquent er kritisk viden om ydeevne for Laravel-applikationer — **N+1-forespørgselproblemet er det enkelt mest almindelige og impactfulde ydelsesspørgsmål** i Laravel, og det at forstå, hvordan man forhindrer det, er essentielt.

Problemet er listefuldigt, fordi Eloquents bekvemme relationsadgang (`$post->author`) stilfærdigt udløser en databaseforespørgsel hver gang, så kode, der fungerer fint med få data, forringes katastrofalt, efterhånden som data vokser (100 poster bliver 101 forespørgsler), ofte først opdaget i produktion under belastning. **Eager loading med `with()`** er den essentielle løsning — indlæsning af relationer på forhånd i et par forespørgsler i stedet for én pr. post — og kendskab til dens variationer (flere, indlejrede, begrænsede eager loads, `withCount`) dækker de almindelige behov.

Ligeledes værdifuldt er det at vide, hvordan man **fanger N+1-problemer** (Debugbar/Telescope for at se forespørgselsantal, `preventLazyLoading()` for at gøre utilsigtede lazy loads til fejl under udvikling), så du finder dem før produktion.
/'ud over N+1 afrunder andre optimiseringer — valg af kun nødvendige kolonner, **chunking/cursors** til behandling af store datasæt uden at opbruge hukommelse, databaseaggregering i stedet for PHP-side collection-behandling og afgørende **indeksering** af filtrerede/joinede kolonner (ofte den største database-niveau-gevinst) — værktøjet.

At forstå disse — især at genkende og løse N+1 med eager loading — er vigtig seniorlevelsviden, der skelner udviklere, der skriver performant Laravel-applikationer, fra dem, hvis apps bliver langsomme, når data vokser, hvilket gør det til et hyppigt relevant og højværdi-emne for at bygge applikationer, der skaleres.