--- title: "Ottimizzare le query Eloquent in applicazioni Laravel: strategie avanzate per la performance di gestionali ed e-commerce" description: "Le query Eloquent lente affliggono il tuo gestionale o e-commerce Laravel? Scopri tecniche avanzate per ottimizzare l'accesso ai dati e migliorare la performance." canonical: "https://www.mauriziofonte.it/blog/post/ottimizzazione-query-eloquent-laravel-performance-gestionali-ecommerce-pmi.html" author: "Maurizio Fonte" date: "2025-01-17T16:22:47+01:00" modified: "2026-04-14T17:48:55+02:00" section: "Laravel" tags: ["Laravel", "Database"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Laravel](https://www.mauriziofonte.it/blog/cat/laravel.html) [Database](https://www.mauriziofonte.it/blog/cat/database.html) # [Ottimizzare le query Eloquent in applicazioni Laravel: strategie avanzate per la performance di gestionali ed e-commerce](https://www.mauriziofonte.it/blog/post/ottimizzazione-query-eloquent-laravel-performance-gestionali-ecommerce-pmi.html) Venerdì 17 Gennaio 2025, alle 16:22 ![Ottimizzare le query Eloquent in applicazioni Laravel: strategie avanzate per la performance di gestionali ed e-commerce](https://www.mauriziofonte.it/image/001120200-ottimizzazione-query-eloquent-laravel-performance-gestionali-ecommerce-pmi.jpg) Nella mia esperienza come ingegnere del software specializzato in PHP e framework come Laravel, ho spesso constatato come la performance di un'applicazione web mission-critical per una PMI dipenda in modo cruciale dall'efficienza con cui interagisce con il database. Laravel, con il suo ORM Eloquent (maturo e costantemente migliorato fino alla versione 12), offre un'interfaccia potente e intuitiva per manipolare i dati. Tuttavia, questa facilità d'uso, se non accompagnata da una profonda comprensione del funzionamento interno, può portare a problemi di performance subdoli e difficili da diagnosticare. In un progetto di ottimizzazione per una piattaforma e-commerce con circa 15.000 prodotti e 200.000 ordini storici, ho ridotto il tempo di caricamento della dashboard principale da 4.2 secondi a 380 millisecondi semplicemente correggendo pattern di query N+1 e aggiungendo indici mirati. Nessuna modifica all'infrastruttura, nessun investimento in hardware: solo ottimizzazione del codice Eloquent e del database. ## Perché le query Eloquent non ottimizzate sono un rischio concreto per il tuo business? Le query lente non sono un problema solo tecnico: impattano direttamente sull'esperienza utente, sulle conversioni e sulla scalabilità del tuo applicativo. Un e-commerce che impiega 5 secondi a caricare la pagina prodotti perde potenziali clienti a ogni secondo di attesa. Un gestionale che rallenta durante la generazione di report rende il tuo team meno produttivo. Il problema è che queste inefficienze sono spesso invisibili in ambiente di sviluppo, dove il database contiene pochi record di test, e emergono con prepotenza solo in produzione, quando i dati crescono e il traffico aumenta. ## L'impatto nascosto delle query non ottimizzate Un utilizzo "ingenuo" di Eloquent, tipico di chi si avvicina al framework senza approfondirne le dinamiche o di chi lavora su codice legacy, può portare a scenari problematici comuni: - **Il famigerato N+1 query problem**: si verifica quando si carica una collezione di modelli e poi, in un loop, si accede a una relazione per ciascun modello, generando una query separata per ogni iterazione. Per una lista di 50 prodotti che mostra il nome del produttore: 1 query per i prodotti + 50 query per i produttori. Con 500 prodotti, il problema si moltiplica per dieci. - **Lazy loading eccessivo**: Eloquent carica le relazioni on-demand se non specificato diversamente. Comodo, ma se accedi a molte relazioni in sequenza, ogni accesso scatena una nuova query con un impatto cumulativo che può essere devastante. - **Selezione di dati superflui**: caricare intere tabelle con `SELECT *` quando servono solo due o tre colonne appesantisce inutilmente la memoria e il trasferimento dati tra database e applicazione. - **Mancanza di indici**: Eloquent scrive le query per te, ma se le tabelle MySQL o PostgreSQL non hanno indici appropriati sulle colonne usate nelle clausole `WHERE`, `JOIN` o `ORDER BY`, le query saranno lente indipendentemente da come Eloquent le costruisce. Ne ho parlato in dettaglio nella guida al [refactoring strategico di database MySQL su Laravel](https://www.mauriziofonte.it/blog/post/rifacimento-strategico-database-mysql-laravel.html). > Questi problemi emergono con prepotenza in produzione, quando l'applicativo deve processare centinaia di transazioni o il portale clienti riceve picchi di traffico. Il risultato: tempi di caricamento biblici, utenti frustrati e risorse server sprecate. ## Strategie per query Eloquent performanti Eloquent e Laravel (dalle versioni 9 alla 12, che ha introdotto miglioramenti significativi) offrono strumenti potenti per scrivere query efficienti. Vediamo le tecniche più impattanti. ### Sconfiggere l'N+1 con l'eager loading La soluzione principale all'N+1 query problem è l'[eager loading](https://laravel.com/docs/12.x/eloquent-relationships#eager-loading), che permette di caricare in anticipo le relazioni necessarie con un numero limitato di query (solitamente due). ```php // N+1: una query per ogni produttore (NON fare così) $prodotti = Prodotto::all(); foreach ($prodotti as $prodotto) { echo $prodotto->produttore->nome; // 1 query per ogni produttore! } // Eager loading: 2 query totali indipendentemente dal numero di prodotti $prodotti = Prodotto::with('produttore')->get(); foreach ($prodotti as $prodotto) { echo $prodotto->produttore->nome; // nessuna query aggiuntiva } // Eager loading di relazioni annidate con notazione puntata $prodotti = Prodotto::with('produttore.recensioni')->get(); // Constrained eager loading: filtra le relazioni caricate $utenti = User::with(['ordini' => function ($query) { $query->where('stato', 'completato') ->orderByDesc('created_at') ->limit(5); }])->get(); ``` A partire da **Laravel 12.8**, è disponibile l'**automatic eager loading**: Eloquent rileva automaticamente quali relazioni vengono accedute e le carica in modo efficiente in background, eliminando l'N+1 senza intervento manuale. Puoi attivarlo per modello specifico (`protected $autoLoadRelations = true`) o globalmente nel tuo `AppServiceProvider`: ```php // AppServiceProvider::boot() - attiva l'eager loading automatico use Illuminate\Database\Eloquent\Model; public function boot(): void { Model::automaticallyEagerLoadRelationships(); // In sviluppo, lancia un'eccezione per lazy loading non intenzionale Model::preventLazyLoading(!app()->isProduction()); } ``` Il metodo `preventLazyLoading()` è un complemento fondamentale: in ambiente di sviluppo, lancia un'eccezione ogni volta che una relazione viene caricata in modo lazy, costringendo lo sviluppatore a usare eager loading esplicito o a delegare all'autoloading. Questo approccio trasforma gli N+1 da bug silenziosi a errori espliciti catturabili in fase di test. ### Selezione selettiva delle colonne Non caricare mai più dati del necessario. Se per la lista fatture del tuo gestionale servono solo ID, numero e data, specifica queste colonne: ```php // Carica solo le colonne necessarie $fatture = Fattura::select('id', 'numero_fattura', 'data_emissione') ->where('anno', 2024) ->get(); // Con eager loading: includi sempre le chiavi esterne $prodotti = Prodotto::with('produttore:id,nome') ->select('id', 'nome', 'prezzo', 'produttore_id') ->get(); // withCount al posto di caricare relazioni intere per contarle $categorie = Categoria::withCount('prodotti') ->orderByDesc('prodotti_count') ->get(); ``` Il metodo `withCount()` è particolarmente importante: se devi solo mostrare quanti prodotti ha ogni categoria, caricare l'intera relazione per poi contarla è uno spreco enorme di memoria e query. `withCount` esegue una subquery COUNT aggregata, molto più efficiente. ### Clausole condizionali e subquery Eloquent offre strumenti eleganti per costruire query dinamiche basate su input variabili: ```php // Query condizionale con when() $ordini = Ordine::query() ->when($request->input('stato'), fn($q, $stato) => $q->where('stato_ordine', $stato)) ->when($request->input('da_data'), fn($q, $data) => $q->where('created_at', '>=', $data)) ->paginate(20); // Subquery per ordinamenti complessi $utenti = User::orderByDesc( Login::select('created_at') ->whereColumn('user_id', 'users.id') ->latest() ->take(1) )->get(); ``` Il metodo `when()` è particolarmente utile per i filtri di ricerca: applica la condizione solo se il valore è truthy, evitando cascate di `if/else` che rendono il codice illeggibile. ### Paginazione efficiente Per elenchi lunghi (storico ordini in un CRM, catalogo prodotti), usa sempre la paginazione integrata (`paginate()` o `simplePaginate()`) invece di caricare tutti i record e paginarli in PHP. `simplePaginate()` è preferibile quando non ti serve il conteggio totale dei record, perché evita una costosa query `COUNT(*)` che su tabelle con milioni di righe può richiedere secondi. Un errore che vedo ripetersi nei gestionali è caricare tutto in memoria e poi filtrare/ordinare in PHP con `Collection::filter()` o `Collection::sortBy()`. Questo funziona con 100 record ma crolla con 100.000: il database è progettato per filtrare e ordinare dati in modo efficiente, PHP no. ### Indici e analisi dei piani di esecuzione Questa non è una funzionalità di Eloquent, ma è la singola ottimizzazione più impattante che puoi fare: **creare indici appropriati sul database**. Assicurati che ci siano indici sulle colonne frequentemente usate nelle clausole `WHERE`, `JOIN`, `ORDER BY` e `GROUP BY`. Il comando [`EXPLAIN`](https://dev.mysql.com/doc/refman/8.4/en/explain.html) di MySQL (o `EXPLAIN ANALYZE` in PostgreSQL) è lo strumento diagnostico fondamentale: mostra il piano di esecuzione della query, rivelando se sta facendo un full table scan (scansione di ogni singola riga) o se utilizza correttamente gli indici. Puoi intercettare le query generate da Eloquent con il metodo `toSql()` e poi analizzarle manualmente: ```php // Ottieni la query SQL generata da Eloquent per analizzarla con EXPLAIN $query = Ordine::with('cliente') ->where('stato', 'in_lavorazione') ->where('created_at', '>=', now()->subMonth()); dd($query->toSql(), $query->getBindings()); // Copia la query e esegui EXPLAIN nel client MySQL per verificare gli indici ``` Un indice composito ben progettato può trasformare una query da 2 secondi a 2 millisecondi. Nel progetto e-commerce che citavo in apertura, metà del guadagno prestazionale è venuto dall'aggiunta di tre indici compositi sulle tabelle ordini e prodotti, non dall'ottimizzazione del codice PHP. ## Monitoraggio e diagnosi con Laravel Telescope Per identificare query inefficienti in fase di sviluppo, [Laravel Telescope](https://laravel.com/docs/12.x/telescope) è uno strumento eccezionale. Traccia tutte le query eseguite durante una richiesta, mostrando il tempo di esecuzione e il numero di query duplicate, permettendoti di individuare facilmente gli N+1 o le query particolarmente lente. L'investimento di tempo per configurarlo è minimo e i benefici sono immediati: smetti di "tirare a indovinare" e inizi a misurare. Telescope è particolarmente utile perché mostra il conteggio delle query per richiesta HTTP. Se una pagina del tuo gestionale esegue 150 query, è quasi certamente affetta da N+1. Con `preventLazyLoading()` attivo in sviluppo, questi problemi diventano impossibili da ignorare: l'applicazione lancia un'eccezione invece di degradare silenziosamente. Per un approccio più completo all'[ottimizzazione del database](https://www.mauriziofonte.it/blog/post/database-optimization-performance-sicurezza-azienda.html), Telescope va combinato con il monitoraggio slow query di MySQL/PostgreSQL e con strumenti di profiling come Clockwork o Laravel Debugbar. ## Quando l'ottimizzazione Eloquent non basta Ci saranno casi in cui, per query estremamente complesse o per esigenze di reporting su grandi moli di dati, anche un Eloquent ottimizzato potrebbe non essere sufficiente. In questi scenari potrebbe essere necessario scrivere query SQL native con `DB::select()`, considerare l'uso di viste materializzate nel database, o implementare strategie di caching a livello di query, come discusso nella guida sul [caching con Redis in Laravel](https://www.mauriziofonte.it/blog/post/ottimizzazione-prestazioni-laravel-12-caching-redis-pmi.html). L'ottimizzazione delle query Eloquent non è un'attività secondaria, ma una disciplina fondamentale per garantire che i gestionali e gli e-commerce della tua PMI siano veloci e scalabili. La differenza tra un applicativo che regge 100 utenti concorrenti e uno che ne regge 10.000 sta spesso tutta nel modo in cui gestisce l'accesso ai dati. Come [ingegnere del software con esperienza specifica in Laravel e architetture database](https://www.mauriziofonte.it/pages/about), posso aiutarti a diagnosticare i colli di bottiglia prestazionali e implementare strategie di ottimizzazione su misura. Se le performance del tuo applicativo Laravel sono una preoccupazione, [contattami per una consulenza](https://www.mauriziofonte.it/pages/contattami) e trasformiamo il tuo database da collo di bottiglia a punto di forza. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteLogging strategico in applicazioni Laravel e Symfony: da semplice debugging a strumento di sicurezza e analisi16 Gennaio 2025](https://www.mauriziofonte.it/blog/post/logging-strategico-laravel-symfony-debugging-sicurezza-analisi-applicativi-pmi.html)[Articolo successivo »Validazione dei dati in ingresso in applicazioni Laravel: oltre le regole base per la robustezza dei gestionali20 Gennaio 2025](https://www.mauriziofonte.it/blog/post/laravel-validazione-dati-input-custom-rule-form-request-sicurezza-gestionali.html) ### Articoli correlati a Ottimizzare le query Eloquent in applicazioni Laravel: strategie avanzate per la performance di gestionali ed e-commerce - [Eloquent ORM avanzato: evitare le query N+1 nei gestionali Laravel](https://www.mauriziofonte.it/blog/post/eloquent-orm-avanzato-evitare-n1-query-gestionali-laravel.html) Le query N 1 non rompono nulla in sviluppo e affondano la produzione: un gestionale con molte relazioni le genera senza accorgersene. Come individuarle · 4 Settembre 2026 ![Eloquent ORM avanzato: evitare le query N+1 nei gestionali Laravel](https://www.mauriziofonte.it/image/005230070-eloquent-orm-avanzato-evitare-n1-query-gestionali-laravel.jpg) - [Eloquent performance: 10 pattern che rallentano le tue query senza che tu lo sappia](https://www.mauriziofonte.it/blog/post/eloquent-performance-pattern-query-lente-ottimizzazione-laravel.html) Ho usato Laravel Telescope su un'applicazione di e commerce per analizzare 48 ore di traffico reale. I risultati erano impietosi: 340 query per · 21 Novembre 2025 ![Eloquent performance: 10 pattern che rallentano le tue query senza che tu lo sappia](https://www.mauriziofonte.it/image/003340070-eloquent-performance-pattern-query-lente-ottimizzazione-laravel.jpg) - [Database Optimization: perché non puoi più permetterti database lenti e inefficaci](https://www.mauriziofonte.it/blog/post/database-optimization-performance-sicurezza-azienda.html) Un database non ottimizzato rallenta operazioni e crescita, aumentando rischi e costi aziendali. Scopri perché investire nella Database Optimization · 20 Mag 2025 ![Database Optimization: perché non puoi più permetterti database lenti e inefficaci](https://www.mauriziofonte.it/image/001210070-database-optimization-performance-sicurezza-azienda.jpg) - [Refactoring database MySQL su Laravel: report da 47 minuti a 11 secondi senza upgrade hardware](https://www.mauriziofonte.it/blog/post/rifacimento-strategico-database-mysql-laravel.html) Un database MySQL da 12 GB su un VPS Contabo, un report mensile che impiegava 47 minuti, 38 indici su una tabella di cui 12 mai utilizzati, e · 26 Giugno 2025 ![Refactoring database MySQL su Laravel: report da 47 minuti a 11 secondi senza upgrade hardware](https://www.mauriziofonte.it/image/001870070-rifacimento-strategico-database-mysql-laravel.jpg) - [Laravel Telescope in produzione: debugging avanzato senza impatto sulle prestazioni](https://www.mauriziofonte.it/blog/post/laravel-telescope-produzione-debugging-avanzato-prestazioni.html) Telescope è uno strumento potente ma va usato in produzione con cautela: senza configurazione adeguata, logga dati sensibili degli utenti e rallenta · 26 Novembre 2025 ![Laravel Telescope in produzione: debugging avanzato senza impatto sulle prestazioni](https://www.mauriziofonte.it/image/002430070-laravel-telescope-produzione-debugging-avanzato-prestazioni.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Ottimizzare le query Eloquent in applicazioni Laravel: strategie avanzate per la performance di gestionali ed e-commerce", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/ottimizzazione-query-eloquent-laravel-performance-gestionali-ecommerce-pmi.html Pubblicato: 2025-01-17 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.