SQL Query Performance
In questo caso particolare, non noterai un’enorme differenza perché 30.000 righe non sono troppo difficili da elaborare per il database. Tuttavia, se stavi parlando di centinaia di milioni di righe o più, vedresti un notevole miglioramento aggregando prima di unirti. Quando lo fai, assicurati che quello che stai facendo sia logicamente coerente: dovresti preoccuparti della precisione del tuo lavoro prima di preoccuparti della velocità di esecuzione.
13 SUGGERIMENTI PER LE PRESTAZIONI DELLE QUERY
Ricordarsi di anteporre i nomi degli oggetti (es. tabella, stored procedure, view) con il suo nome proprietario / schema.
Motivo: se il nome del proprietario / schema non viene fornito, il motore di SQL Server tenta di trovarlo in tutti gli schemi fino a quando l’oggetto non lo trova. SQL Server engine non cercherà la tabella al di fuori del suo proprietario/schema se viene fornito il nome del proprietario/schema.
L’operatore *
Non utilizzare l’operatore * nelle istruzioni SELECT. Invece, utilizzare i nomi delle colonne.
Motivo: SQL Server esegue la scansione di tutti i nomi delle colonne e sostituisce * con tutti i nomi delle colonne delle tabelle nell’istruzione SQL SELECT. Fornire nomi di colonne evita questa ricerca e sostituzione e migliora le prestazioni.
Colonne Nullable
Evitare di utilizzare NOT IN quando si confrontano con colonne nullable. L’uso NON ESISTE invece.
Motivo: Quando NOT IN viene utilizzato nella query (anche se la query non restituisce righe con i valori null), SQL Server controllerà ogni risultato per vedere se è nullo o meno. L’uso di NOT EXISTS non farà il confronto con null. Inoltre, NOT EXISTS restituisce solo due stati (true o false), mentre NOT IN può restituire fino a tre stati (true, false, NULL) e potrebbe non darti il risultato che ti aspettavi.
Variabili di tabella e join
Evitare l’uso di variabili di tabella nei join. Utilizzare invece tabelle temporanee, CTES (espressioni di tabella comuni) o tabelle derivate nei join.
Motivo: Anche se le variabili di tabella sono molto veloci ed efficienti in molte situazioni, il motore di SQL Server la vede come una singola riga. Per questo motivo, SQL produrrà un piano di esecuzione che si esibirà orribilmente quando viene utilizzato nei join.
Nomi di stored procedure
Non iniziare il nome della stored procedure con sp_.
Motivo: Quando la stored procedure è denominata sp_ o SP_, SQL Server controlla sempre nel database system/master anche se viene fornito il nome del proprietario/schema. Fornire un nome senza SP_ a una stored procedure evita questo controllo non necessario nel database system/master in SQL Server.
Usa SET NOCOUNT ON
Usa SET NOCOUNT ON con operazioni DML.
Motivo: quando si eseguono operazioni DML (es. INSERISCI, ELIMINA, SELEZIONA e AGGIORNA), SQL Server restituisce sempre il numero di righe interessate. Nelle query complesse con molti join, questo diventa un enorme problema di prestazioni. L’utilizzo di SET NOCOUNT ON migliorerà le prestazioni perché non terrà traccia del numero di righe interessate.
Evita di usare GROUP BY, ORDER BY e DISTINCT
Evita di usare GROUP BY, ORDER BY e DISTINCT quando possibile.
Motivo: Quando si utilizza GROUP BY, ORDER BY o DISTINCT, SQL Server Engine crea una tabella di lavoro e inserisce i dati nella tabella di lavoro. Successivamente, organizza questi dati nella tabella di lavoro come richiesto dalla query, quindi restituisce il risultato finale.
Controlla indici
Dovrebbero esserci indici su tutti i campi utilizzati nelle porzioni WHERE e JOIN dell’istruzione SQL.
Motivo: quando i campi non sono indicizzati, SQL Server eseguirà in genere una scansione completa della tabella e ciò potrebbe ridurre le prestazioni. A meno che la tabella non sia molto piccola, una scansione della tabella tende a produrre le peggiori prestazioni di tutti i tipi di letture del database.
Usa lo stesso tipo di dati sulle clausole JOIN e WHERE
Questo è più facile a dirsi che a farsi a seconda delle tue autorizzazioni per apportare modifiche allo schema.
Motivo: quando si uniscono o si confrontano due campi con tipi di dati diversi, SQL deve eseguire una conversione al volo del campo prima di poter eseguire un confronto, anche se i campi sono indicizzati. Se i tipi di dati non corrispondenti sono inevitabili, prova a trasmettere il tipo di dati più grande al tipo di dati più piccolo quando possibile.
Evita di usare i campi calcolati nelle clausole JOIN e WHERE
Questo può essere fatto creando un campo con i valori calcolati utilizzati nel join sulla tabella. Vedi sotto.