Come si risolvono le query N+1 e si ottimizza Eloquent?

Question

Accepted Answer

Il **problema delle query N+1** — dove accedere alle relazioni in un ciclo attiva una query separata per record — è il problema di performance più comune in Eloquent. L'**eager loading** con `with()` è la fix principale, insieme ad altre ottimizzazioni (selezione di colonne, chunking, indicizzazione).

## Il problema N+1 e la sua soluzione

```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()`** carica le relazioni in modo eager fin dall'inizio (una query extra per relazione invece di una per record), trasformando 101 query in 2 — un miglioramento drastico. Questa è l'ottimizzazione essenziale di Eloquent.

## Variazioni di 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)
```

## Catturare N+1 automaticamente

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

Strumenti come **Debugbar/Telescope** mostrano il conteggio delle query per pagina (individua N+1 visivamente), e `preventLazyLoading()` trasforma i caricamenti lazy accidentali in errori durante lo sviluppo.

## Altre ottimizzazioni di Eloquent

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

## Perché è importante

Risolvere le query N+1 e ottimizzare Eloquent è una conoscenza di performance critica per le applicazioni Laravel — il **problema delle query N+1 è il singolo problema di performance più comune e impattante** in Laravel, e capire come prevenirlo è essenziale.

Il problema è subdolo perché l'accesso conveniente alle relazioni di Eloquent (`$post->author`) attiva silenziosamente una query al database ogni volta, quindi il codice che funziona bene con pochi dati si degrada catastroficamente man mano che i dati crescono (100 record diventano 101 query), spesso scoperto solo in produzione sotto carico. **L'eager loading con `with()`** è la fix essenziale — caricare le relazioni in anticipo in un paio di query invece di una per record — e conoscerne le variazioni (multiple, nidificate, eager load vincolati, `withCount`) copre le necessità comuni.

Egualmente prezioso è sapere come **catturare i problemi N+1** (Debugbar/Telescope per vedere i conteggi delle query, `preventLazyLoading()` per trasformare i caricamenti lazy accidentali in errori durante lo sviluppo), così li trovi prima della produzione.

Oltre a N+1, altre ottimizzazioni — selezione solo delle colonne necessarie, **chunking/cursor** per elaborare dataset grandi senza esaurire la memoria, aggregazione database rispetto all'elaborazione lato PHP, e crucialmente **indicizzazione** delle colonne filtrate/unite (spesso il guadagno più grande a livello di database) — completano il toolkit.

Comprendere questi — specialmente riconoscere e risolvere N+1 con eager loading — è una conoscenza importante a livello senior che distingue gli sviluppatori che scrivono applicazioni Laravel performanti da quelli le cui app rallentano drasticamente man mano che i dati crescono, rendendolo un argomento frequentemente rilevante e ad alto valore per costruire applicazioni che scalano.