Per vedere la query preparata dal Query Builder Laravel usa toSql e getBindings sul builder, prima di chiamare get. Il primo restituisce SQL con segnaposto; il secondo contiene i valori che verranno associati ai parametri.
Questo esempio è riferito a Laravel 12 e presuppone una tabella users con una colonna name. Serve a ispezionare la costruzione della query, senza leggere i risultati dal database.
use Illuminate\Support\Facades\DB;
$query = DB::table('users')
->where('name', 'Rocco')
->orderBy('id')
->limit(10);
dump($query->toSql(), $query->getBindings());Perché i valori non compaiono dentro toSql
I binding tengono separati istruzione e valori. Vedere un punto interrogativo al posto del nome non significa che il filtro sia assente: bisogna leggere insieme SQL e parametri.
La sintassi esatta dell’istruzione dipende dal driver. Virgolette e dettagli generati per MySQL possono differire da quelli di PostgreSQL o SQLite, pur rappresentando la stessa intenzione applicativa.
Ottenere una rappresentazione più leggibile
Nella sezione debugging del Query Builder sono documentati dumpRawSql e ddRawSql, che mostrano una rappresentazione con i binding sostituiti. Il secondo interrompe l’esecuzione della richiesta.
$query->dumpRawSql();La userei per leggere la query durante lo sviluppo. Non costruirei un interpolatore con sostituzioni manuali dei punti interrogativi: stringhe, date, booleani e caratteri speciali rendono facile produrre un testo fuorviante.
Osservare ciò che viene davvero eseguito
Il builder descrive una query. Un percorso applicativo può eseguirne molte altre, per esempio caricando relazioni Eloquent. Per osservarle, Laravel offre eventi e strumenti descritti nella guida agli eventi delle query.
Il query log richiede l’abilitazione sulla connessione pertinente e conserva informazioni in memoria. Non lo lascerei attivo indiscriminatamente su processi lunghi o richieste con molti risultati.
Passare dal debug all’analisi delle prestazioni
Una query leggibile non è ancora una query efficiente. Per capire un rallentamento servono durata, frequenza, volume dei dati e piano di esecuzione sul database pertinente.
Controllerei prima se il problema è una singola query costosa oppure la ripetizione della stessa lettura. Un indice può aiutare il primo caso; un caricamento delle relazioni progettato meglio può risolvere il secondo.
SQL e binding possono contenere dati personali o segreti applicativi. Limiterei raccolta, accesso e conservazione ai dati necessari per la diagnosi, senza esporre l’output di debug nelle pagine pubbliche.