L'amministratore del database si impegna sempre per ottimizzare le prestazioni delle query di SQL Server. Il primo passaggio nell'ottimizzazione delle prestazioni della query consiste nell'analisi del piano di esecuzione di una query. In alcune condizioni, Query Optimizer di SQL Server può creare piani di esecuzione diversi. A questo punto, vorrei aggiungere alcune note su SQL Server Query Optimizer. SQL Server Query Optimizer è un ottimizzatore basato sui costi che analizza i piani di esecuzione e decide il piano di esecuzione ottimale per una query. La parola chiave significativa per Query Optimizer di SQL Server è un piano di esecuzione ottimale che non è necessariamente il piano di esecuzione ottimale. Ecco perché, se Query Optimizer di SQL Server tenta di trovare il miglior piano di esecuzione per ogni query, richiede più tempo e danneggia le prestazioni di SQL Server Engine. In SQL Server 2016, Microsoft ha aggiunto una nuova funzionalità a SQL Server Management Studio, denominata Compare Showplan. Questa caratteristica ci consente di confrontare due diversi piani di esecuzione. Allo stesso tempo, possiamo utilizzare questa opzione offline, il che significa che non è necessario connettere l'istanza di SQL Server. Immagina di scrivere una query e questa query funziona bene nell'ambiente TEST ma in PROD (ambiente di produzione), funziona molto male. Per gestire questo problema, dobbiamo confrontare i piani di esecuzione. Prima di questa funzionalità, aprivamo due SQL Server Management Studios e affiancavamo i piani di esecuzione, ma questo metodo era molto scomodo.
Come confrontare due piani di esecuzione?
In questa dimostrazione, utilizzeremo il database AdventureWorks e confronteremo due piani di esecuzione che hanno una versione del modello di stima della cardinalità diversa e rileveremo questa differenza con Confronta Showplan.
Inizialmente, apriremo una nuova finestra di query in SQL Server Management Studio e faremo clic su Includi piano di esecuzione effettivo e quindi eseguire la query seguente.
SELECT
soh.[SalesPersonID]
,p.[FirstName] + ' ' + COALESCE(p.[MiddleName], '') + ' ' + p.[LastName] AS [FullName]
,e.[JobTitle]
,st.[Name] AS [SalesTerritory]
,soh.[SubTotal]
,YEAR(DATEADD(m, 6, soh.[OrderDate])) AS [FiscalYear]
FROM [Sales].[SalesPerson] sp
INNER JOIN [Sales].[SalesOrderHeader] soh
ON sp.[BusinessEntityID] = soh.[SalesPersonID]
INNER JOIN [Sales].[SalesTerritory] st
ON sp.[TerritoryID] = st.[TerritoryID]
INNER JOIN [HumanResources].[Employee] e
ON soh.[SalesPersonID] = e.[BusinessEntityID]
INNER JOIN [Person].[Person] p
ON p.[BusinessEntityID] = sp.[BusinessEntityID]
In questo passaggio, salveremo il nostro primo piano di esecuzione. Fai clic con il pulsante destro del mouse in un punto qualsiasi del piano di esecuzione e fai clic su Salva piano di esecuzione con nome e salva il piano di esecuzione come ExecutionPlan_CE140.sqlplan.
Ora apriremo una nuova scheda query in SQL Server Management Studio ed eseguiremo la query seguente. In questa query, aggiungeremo l'hint per la query FORCE_LEGACY_CARDINALITY_ESTIMATION alla fine della query che obbliga a utilizzare la versione precedente del modello di stima della cardinalità.
Il compito di Stima della cardinalità è prevedere quante righe restituirà la nostra query.
SELECT
soh.[SalesPersonID]
,p.[FirstName] + ' ' + COALESCE(p.[MiddleName], '') + ' ' + p.[LastName] AS [FullName]
,e.[JobTitle]
,st.[Name] AS [SalesTerritory]
,soh.[SubTotal]
,YEAR(DATEADD(m, 6, soh.[OrderDate])) AS [FiscalYear]
FROM [Sales].[SalesPerson] sp
INNER JOIN [Sales].[SalesOrderHeader] soh
ON sp.[BusinessEntityID] = soh.[SalesPersonID]
INNER JOIN [Sales].[SalesTerritory] st
ON sp.[TerritoryID] = st.[TerritoryID]
INNER JOIN [HumanResources].[Employee] e
ON soh.[SalesPersonID] = e.[BusinessEntityID]
INNER JOIN [Person].[Person] p
ON p.[BusinessEntityID] = sp.[BusinessEntityID]
OPTION (USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION')); Faremo clic su Confronta Showplan e seleziona il piano di esecuzione precedente che è stato salvato come ExecutionPlan_CE140.sqlplan.
L'immagine seguente illustra la prima schermata dell'esecuzione di SQL Server confronta il piano e le aree evidenziate di colore rosa definiscono operazioni simili.
Se si fa clic su qualsiasi operatore nella schermata del piano di esecuzione inferiore o superiore, SQL Server Management Studio evidenzia altri operatori simili. Sul lato destro del pannello, puoi trovare le proprietà e i dettagli di confronto delle proprietà.
In questo passaggio, cambieremo le opzioni di analisi ShowPlan ed evidenzieremo l'operatore non corrispondente. Nella parte inferiore dello schermo, possiamo vedere l'Analisi Showplan pannello. Se cancelliamo Evidenzia operazioni simili e seleziona Evidenzia operatori che non corrispondono a segmenti simili SQL Server Management Studio mette in evidenza un operatore impareggiabile. Successivamente, fai clic su Seleziona operatori nel piano di esecuzione sotto e sopra nel pannello. SQL Server Management Studio confronta le proprietà degli operatori selezionati e inserisce i segni di disuguaglianza nei valori non identici.
Se analizziamo questa schermata in modo più dettagliato, la prima cosa è la Versione del modello di stima della cardinalità differenza. La prima versione della query è 70 e la seconda è 140. Questa differenza influisce sul Numero stimato di righe . Il motivo principale che causa il diverso Numero stimato di righe è una versione diversa della stima della cardinalità. Pertanto, la versione della stima della cardinalità influisce direttamente sulle metriche stimate della query. Per questo confronto di query, possiamo concludere che la query con versione di stima della cardinalità 140 ha prestazioni migliori perché il numero stimato di righe è vicino al Numero effettivo di righe . Questo caso può essere chiarito dalla tabella seguente.
[id tabella=50 /]
Se vogliamo vedere i piani di esecuzione fianco a fianco sullo stesso schermo, possiamo fare clic su Attiva/disattiva orientamento splitter .
Ora faremo un'altra dimostrazione. Esamineremo la query seguente e confronteremo i piani di esecuzione prima e dopo la creazione dell'indice.
Quando esaminiamo il piano di esecuzione della query seguente, si consiglia di creare un indice non in cluster.
SELECT [CarrierTrackingNumber] FROM [Sales].[SalesOrderDetail] WHERE [SalesOrderDetailID]=12
Applicheremo l'indice consigliato ed eseguiremo nuovamente la stessa query.
CREATE NONCLUSTERED INDEX Index_NC ON [Sales].[SalesOrderDetail] ([SalesOrderDetailID]) GO SELECT [CarrierTrackingNumber] FROM [Sales].[SalesOrderDetail] WHERE [SalesOrderDetailID]=12
In quest'ultimo passaggio, confronteremo i piani di esecuzione.
Nell'immagine sopra, possiamo ottenere diverse informazioni sui piani di esecuzione. Ma la differenza principale è l'Operazione Logica campo. Uno di questi è Ricerca indice e un altro è Scansione indice e questa differenziazione dell'operazione porta a valori metrici stimati ed effettivi dissimili. Infine, l'operatore Index Seek ha prestazioni migliori rispetto all'operatore Index Scan.
Conclusioni
Come accennato nell'articolo, la funzione Confronta Showplan offre alcuni vantaggi allo sviluppatore di database o all'amministratore. Alcuni di questi possono essere contati come:
- Semplice per confrontare la differenza di due piani di esecuzione.
- Rilevamento semplice dei problemi di prestazioni delle query in diverse versioni di SQL Server.
- Semplice da rilevare problemi di prestazioni delle query in diversi ambienti.
- Chiarisce semplicemente le modifiche al piano di esecuzione prima e dopo la creazione dell'indice.
Riferimenti
- Stima della cardinalità (SQL Server)
- Guida all'architettura di elaborazione delle query
