Ottimizzazione delle prestazioni delle query

Al termine della scrittura di una query / proc / funzione memorizzata, qual è il modo più informativo per ottenere rapidamente alcuni parametri di prestazione? Esegui la query e visualizzi il piano di esecuzione effettivo? In tal caso, quali sono le cose che cerchi? Ovviamente le scansioni di tabelle / indici sono i bit hit, ma cos'altro?

Per una rapida valutazione, estrarre il piano di esecuzione da SSMS e accedere a Plan Explorer .

• Controlla le operazioni più costose per qualsiasi cosa inaspettata. Ordinamento, tabelle di lavoro, operatori di join inappropriati (ad es. Loop nidificato in cui ci si aspetta una fusione o un hash).
• Guarda i conteggi delle righe in ogni fase del piano, sono ampiamente compresi nell'intervallo che ti aspetti di vedere?
• Guarda le righe stimate rispetto a quelle effettive. Se i tuoi dati reali sono vicini alle stime, è più probabile che tu abbia un buon piano. Se ci sono grandi variazioni, scopri perché (ad esempio statistiche mancanti e / o obsolete).
• Valuta il potenziale per problemi di sniffing dei parametri. Cerca le aree in cui la cardinalità può variare e verifica la presenza di una serie di parametri di input.

Un sacco di materiale di riferimento disponibile gratuitamente là fuori, i piani di esecuzione di SQL Server di Grant Fitchley sono un buon inizio. Ho anche trovato molto utili i post sul blog e l'ebook di Joe Chang sui costi del piano di esecuzione.

Principalmente, tutto ciò che faccio è solo eseguire la query e scoprire come viene eseguita rispetto ai dati del mondo reale. Se c'è un problema, allora dai un'occhiata ai piani di esecuzione.

Per quanto riguarda i piani di esecuzione, Brad McGehee ha un interessante articolo sull'argomento.

In esso dice:

Se in uno dei piani di esecuzione viene visualizzato uno dei seguenti elementi, è necessario considerare i segnali di avvertimento e indagare per potenziali problemi di prestazioni. Ognuno di essi è tutt'altro che ideale dal punto di vista delle prestazioni.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

Non è sempre possibile evitarli, ma più è possibile evitarli, maggiori saranno le prestazioni della query.

SET STATISTICS IO ON

In generale, il "numero di letture logiche" dovrebbe essere il più basso possibile. Le poche pagine toccate per completare la query, migliore sarà il piano poiché (in genere) sarà più veloce, un impatto minore su CPU, RAM e IO del disco.

Questo ti guiderà quando la modifica degli indici o il re-factoring di SQL stanno effettivamente aiutando. L'esame del "tempo di esecuzione in millisecondi" varierà anche con lo stesso piano SQL e query - le letture logiche rimarranno coerenti per qualsiasi dato piano di query.

Anche le "letture fisiche" dovrebbero essere molto basse (ed essere zero e rimanere zero per le successive esecuzioni). In caso contrario, consultare l'utilizzo della memoria di SQL Server (durata della pagina, ecc.).