Come è possibile analizzare il piano di esecuzione di una query ? Con il Profiler acceso o con il SQL Sentry (che ho appena scaricato ma mi pare di vedere "Gratis per 15gg" )?
Con il Managament Studio non saprei proprio come analizzare il piano di esecuzione!
Per fortuna/purtroppo, anche qui vale la legge del "No Pain, no Gain". Analizzare un piano di esecuzione non è proprio un esercizio semplicissimo, soprattutto all'inizio. La soddisfazione che si trae però dall'investigazione e dalla risoluzione
dei problemi di performance non è seconda a nessuno.
Per visualizzare il piano di esecuzione di una query (se stai usando SSMS), ti basta premere CTRL+M o aprire il menu Query, "Include Actual Execution Plan". Il piano di esecuzione apparirà in un nuovo tab, accanto a quello dei messaggi
(Results|Messages|Execution Plan).
Il piano appare come una serie di flussi\pipelines (si legge da dx verso sx), attraverso i quali i dati vengono trasportati, trasformati, aggregati, ordinati, divisi da operatori che il query optimizer ha selezionato tra i disponibili, nel tentativo di ottenere
la sequenza di operazioni più efficiente che possa portare al risultato richiesto (estrema sinistra del piano). Tale efficienza è esposta come "costo" dell'operazione in relazione al totale. In alcuni casi questo costo è uno dei campanelli
di allarme che ti fa capire che forse un particolare passaggio sta "pesando" troppo sul totale, rappresentando un problema\collo di bottiglia.
Se provi a posizionare il cursore su di un operatore, troverai la sua relativa schermata di riepilogo, con una breve descrizione e una serie di utilissimi attributi che - a prima vista ti faranno venire di mal di testa - ma quando prenderai confidenza
ti sapranno dire moltissimo su ciò che sta accadendo ai tuoi dati in quella particolare operazione; come per ogni cosa, l'esperienza aiuta moltissimo nell'interpretazione dei risultati, pertanto il mio consiglio è di provare ad analizzare qualche semplicissimo
piano di esecuzione di una query prodotta da te, su una tabella che conosci (come cardinalità, copertura di indici, statistiche etc.).
Parti con una sola tabella, verifica quali operatori SQL Server ha selezionato e leggi due righe su quel particolare operatore: cosa rappresenta, cosa fa (i.e. l'operatore SORT li ordina. L'operatore FILTER li filtra. L'operatore Clustered Index Scan percorre
un indice cluster...)
Non mi dilungo oltremodo, perché davvero - è difficile essere sintetici su un argomento così vasto...prova con semplici statement prima, ESPLORA il risultato e tenta di capire perché SQL Server ha avuto bisogno di aggregare, di ordinare, di percorrere, di
calcolare...guarda il costo di ogni operatore. Se SQL Server ti consiglia un indice, NON CREARLO ;) , tenta di capire il perché te lo suggerisce, e se puoi restringere il numero di campi che richiedi in SELECT. Esamina anche le frecce che uniscono gli operatori...sono
le famose pipeline dentro le quali viaggiano i tuoi dati. Guarda se SQL Server si aspetta di lavorare con un numero di righe simile a quello che effettivamente ha trovato. Cominciamo così, vediamo se ti viene l'appetito...
In chiusura,
come non consigliarti il solito ebook gratuito...
Lentezza in esecuzione select
