Introduzione
La query SQL descrive il risultato atteso, non il modo per ottenere il risultato. L'insieme di passaggi specifici che il server deve eseguire per restituire il risultato è chiamato piano di esecuzione della query. Il piano è costruito dall'ottimizzatore. La selezione di un piano influisce sulla velocità di esecuzione, il che lo rende uno degli elementi più importanti dell'analisi dei problemi di prestazioni delle query.
Il piano di esecuzione comprende gli operatori e le loro proprietà che sono correlati tra loro nella forma della struttura ad albero. Ogni operatore è responsabile di un'operazione logica o fisica separata. Tutti insieme, garantiscono il risultato descritto nel testo della query. All'interno dell'albero, gli operatori sono rappresentati dagli oggetti classe nella memoria di SQL Server. Gli utenti del server (ovvero io e te) vedono la descrizione generata in formato XML con uno schema specifico, che viene visualizzato graficamente dall'ambiente SQL Server Management Studio (SSMS).
Ci sono molti diversi operatori di piani e anche più proprietà. Inoltre, di tanto in tanto ne emergono di nuovi. Questo articolo non osa descrivere tutta la possibile varietà di operatori. Vorrei invece condividere le aggiunte più interessanti su questo argomento e ricordare alcuni vecchi ma utili elementi.
Versione server
A volte puoi trovare richieste per la versione server sui forum, anche se il piano di query è fornito nel formato corretto (XML). Invece, puoi risparmiare tempo e aprire il piano di esecuzione come XML. E il primo elemento che descrive il piano ti mostrerà la versione del server nella proprietà Build.
Questo metodo non consente di recuperare informazioni complete sull'edizione server, ma nella maggior parte dei casi è sufficiente per capire di cosa ci occupiamo.
Numero di righe della tabella
La seconda domanda frequente è "Quante righe contiene la tua tabella?". Queste informazioni possono essere recuperate anche dal piano di query (a partire dalla versione server 2008). Per questo, dobbiamo selezionare l'operatore di accesso ai dati (Scan o Seek) di una tabella in questione e dare un'occhiata alla TableCardinality proprietà. C'è un'altra proprietà interessante, Dimensione riga stimata per la specifica della dimensione della riga e la valutazione approssimativa della tabella o della dimensione dell'indice (dato che la tabella non è compressa).
Vorrei notare che questo non è un numero reale di righe in una tabella, ma i dati delle statistiche degli oggetti. Tuttavia, questi dati sono la base per le decisioni che l'ottimizzatore prende durante la creazione di una query.
Contesto
Il piano di query salva le impostazioni SET importanti per le quali è stato creato. Per visualizzare le impostazioni, devi selezionare un elemento radice nel piano ed espandere Imposta opzioni proprietà. Ad esempio, possiamo sapere se il piano è stato creato con ARITHABORT opzione abilitata (la differenza di questa impostazione spesso porta a due diversi piani e situazioni con uno sniffing dei parametri errato).
Numero di CPU
Possiamo recuperare il numero di processori disponibili per l'ottimizzatore. Per questo, dobbiamo aprire OptimizerHardwareDependentPropertie s -> EstimatedAvailableDegreeOfParallelism parametro nello stesso elemento radice e moltiplicarlo per 2. Se è disponibile un solo processore, non è necessario moltiplicarlo.
2*2 =4, sono disponibili 4 CPU. In effetti, ho un processore a 4 core sul mio computer e tutti e 4 i core sono disponibili per il server. Queste informazioni possono aiutarti a rilevare la macchina su cui è stato generato il piano.
Versione per la stima della cardinalità
A partire da SQL Server 2014, sono diventate disponibili diverse versioni di Cardinality Estimator (RU). Questo meccanismo influisce sulla maggior parte delle decisioni prese dall'ottimizzatore durante la selezione di un piano. Puoi recuperare la versione di Cardinality Estimator da CardinalityEstimationModelVersion proprietà dell'operatore root.
- 0 – SQL Server <=2012
- 120 – SQL Server 2014
- 130 – SQL Server 2016
- 140 – SQL Server vNext
Tempo di esecuzione della query e tempo di attesa
A partire da SQL Server 2016 SP1, il piano di query effettivo include informazioni sul tempo di esecuzione e sul tempo del processore. Per recuperare questi dati, devi espandere QueryTimeStats proprietà nell'elemento radice e visualizzare i valori di CpuTime e Tempo trascorso . Non è necessario abilitare la raccolta del tempo di esecuzione o chiedere "per quanto tempo è stata eseguita la query?" più:tutte queste informazioni sono incluse nel piano.
Il secondo miglioramento notevole è la top 10 delle attese più lunghe durante l'esecuzione della query. Per questo, abbiamo bisogno di espandere WaitStats proprietà nell'elemento radice. Questa aggiunta consente di ottenere motivi più precisi per l'esecuzione lenta delle query e semplifica notevolmente la diagnostica.
Tipi di parametri
L'Elenco parametri la proprietà, che elenca i parametri utilizzati nella query, esisteva nel piano molto tempo fa. Tuttavia, a partire da SQL Server 2016 SP1, il Tipo di dati parametro la proprietà è stata aggiunta alla definizione del parametro. Questa proprietà memorizza il tipo di dati del parametro. Può essere utile per comprendere i problemi con la conversione del tipo.
Numero di righe lette e numero stimato di righe da leggere
Il piano di esecuzione include due proprietà molto importanti, il numero effettivo di righe e il numero stimato di righe. Queste proprietà contengono informazioni sul numero di righe restituite dall'operatore di lettura dati, ma non sul numero di righe effettivamente lette. Le proprietà Numero di righe lette e Numero stimato di righe da leggere rispondono a questa domanda e consentono di recuperare il numero di righe che il server ha effettivamente letto o che leggerà. La proprietà ActualRowsRead (numero di righe lette in SSMS) è disponibile a partire da SQL Server 2012 SP3, 2014 SP2, 2016 SP1. EstimatedRowsRead (Numero stimato di righe da leggere in SSMS) è disponibile a partire da SQL Server 2016 SP1.
Statistiche IO e tempo di esecuzione dell'operatore
Esistono diverse proprietà molto utili stabilite in SQL Server 2016, 2014 SP2 e disponibili nel piano di query effettivo. Si tratta di metriche IO (se un operatore ha IO) – Statistiche IO effettive, CPU e tempo di esecuzione metriche – Statistiche del tempo effettivo e metriche di memoria (a partire da SP1 2016, se un operatore richiede memoria).
Le proprietà includono le seguenti nuove metriche che possono essere suddivise in thread in caso di piano parallelo:
- Elapsedms effettivi
- CPU effettive
- Scansioni effettive
- Letture logiche effettive
- Letture fisiche effettive
- Avanzamenti effettivi
- ActualLobLogicalReads
- ActualLobPhysicalReads
- ActualLobReadAheads
- InputMemoryGrant
- OutputMemoryGrant
- UsedMemoryGrant
Come puoi vedere dall'elenco sopra, puoi recuperare informazioni complete sull'esecuzione di un dato operatore, IO consumato e memoria. Nelle ultime versioni di SSMS, queste metriche sono rappresentate nella finestra delle proprietà. Se utilizzi una versione precedente di SSMS, puoi recuperarli aprendo il piano come XML. Secondo me, ora c'è tutto per mostrare le percentuali non in base al costo stimato, ma in base alle risorse effettive trascorse (ho creato un suggerimento su Connect. Quindi, se ti piace l'idea, vota a favore).
Informazioni sui flag di traccia abilitati
I flag di traccia in SQL Server sono "interruttori" speciali dal comportamento predefinito del server a un comportamento diverso. A partire da SQL Server 2014 SP2 e 2016 SP1, le informazioni sui flag di traccia abilitati sono disponibili nella proprietà TraceFlags dell'elemento specifico. Può includere fino a 100 flag abilitati contemporaneamente al momento della creazione della query.
Informazioni sulla fuoriuscita di dati in tempdb
Alcuni operatori del piano, ad esempio Ordina o Corrispondenza hash, richiedono memoria durante l'esecuzione della query. Tuttavia, il volume di memoria viene calcolato al momento della compilazione. A causa di vari motivi (ad es. valutazione errata del numero o delle righe presunte), il volume di memoria può essere calcolato in modo errato. Se viene allocata meno memoria di quella necessaria per l'esecuzione, il server dovrà trasferire i dati a tempdb. Rallenta l'esecuzione delle query. L'attenzione su tale situazione è stata introdotta nel server 2012, ma a partire da SQL Server 2012 SP3, 2014 SP2, 2016, le informazioni diagnostiche sono state ampliate e ora includono il volume dei dati versati e dei dati letti. Quindi, puoi valutare il problema e prendere le misure adeguate.
Conclusione
Il piano di esecuzione include molte informazioni utili, il piano di query effettivo include ancora più informazioni e il piano di query effettivo nelle ultime versioni di SQL Server è solo una miniera di informazioni utili. Questo articolo non ha lo scopo di insegnare a qualcuno ad analizzare i piani di query. Invece, ho considerato le proprietà del piano più interessanti, comprese quelle nuove e quelle vecchie, ma sottovalutate. Spero che questo articolo ti aiuti la prossima volta che dovrai analizzare le prestazioni della query.
L'articolo è stato tradotto dal team di Codingsight con il permesso dell'autore.
Strumento utile:
dbForge Query Builder per SQL Server:consente agli utenti di creare query SQL complesse in modo rapido e semplice tramite un'interfaccia visiva intuitiva senza la scrittura manuale del codice.
