Più di tre anni fa, ho pubblicato una correzione su Plan Explorer per quanto riguarda le stime di cardinalità errate prodotte da Showplan XML di SQL Server, nel caso di ricerche chiave/RID con un predicato di filtro in SQL Server 2008 e versioni successive. Ho pensato che sarebbe stato interessante guardare indietro ed entrare un po' più nel dettaglio di uno di questi piani e delle iterazioni che abbiamo eseguito per assicurarci di visualizzare le metriche corrette, indipendentemente da ciò che Management Studio mostra. Anche in questo caso, questo lavoro è stato in gran parte svolto da Brooke Philpott (@MacroMullet) e Greg Gonzalez (@SQLsensei) e con il grande contributo di Paul White (@SQL_Kiwi).
Questo è abbastanza simile alla domanda che ho presentato nel mio post precedente, che proveniva da Paul (e che richiederebbe del lavoro per riprodursi esattamente nelle versioni moderne di AdventureWorks, dove almeno le date di transazione sono cambiate):
SELECT
th.ProductID,
p.Name,
th.TransactionID,
th.TransactionDate
FROM Production.Product AS p
JOIN Production.TransactionHistory AS th ON
th.ProductID = p.ProductID
WHERE
p.ProductID IN (1, 2)
AND th.TransactionDate BETWEEN '20070901' AND '20071231'; Il piano di Management Studio sembrava sufficientemente corretto:
Tuttavia, se guardi più da vicino, sembra che ShowPlan abbia spostato il numero stimato di esecuzioni dalla ricerca della chiave direttamente al numero stimato di righe per lo scambio finale:
A prima vista, il diagramma del piano grafico in Plan Explorer sembra abbastanza simile al piano prodotto da SSMS:
Ora, nel processo di sviluppo di Plan Explorer, abbiamo scoperto diversi casi in cui ShowPlan non riesce a ottenere risultati matematici corretti. L'esempio più ovvio sono le percentuali che superano il 100%; lo otteniamo bene nei casi in cui SSMS è ridicolmente disattivato (lo vedo meno spesso oggi rispetto al passato, ma succede ancora).
Un altro caso è dove, a partire da SQL Server 2008, SSMS ha iniziato a inserire le righe totali stimate anziché le righe per esecuzione insieme alle ricerche, ma solo nei casi in cui un predicato viene inviato alla ricerca (come nel caso di questo bug segnalato da Paul, e questa più recente osservazione di Joey D'Antoni). Nelle versioni precedenti di SQL Server (e con funzioni e spool), in genere mostravamo il numero di righe stimato in uscita da una ricerca moltiplicando le righe stimate per esecuzione (in genere 1) per il numero stimato di righe in base a SSMS. Ma con questa modifica, conteremmo troppo, poiché l'operatore ora sta già facendo quei calcoli. Quindi, nelle versioni precedenti di Plan Explorer, rispetto al 2008+, vedresti questi dettagli nelle descrizioni comandi, nelle linee dei connettori o nelle varie griglie:
(Da dove provengono 1.721? 67,5 esecuzioni stimate x 25,4927 righe stimate.)
Nel 2012 abbiamo risolto parte di questo problema non eseguendo più questa operazione matematica e basandoci esclusivamente sui conteggi di righe stimati provenienti dalla ricerca della chiave. Questo era quasi corretto, ma stavamo ancora facendo affidamento sul conteggio delle righe stimato che ShowPlan ci stava fornendo per lo scambio finale:
Abbiamo affrontato rapidamente anche questo problema, nella versione 7.2.42.0 (rilasciata ad Halloween 2012), e ora riteniamo di fornire informazioni molto più accurate di Management Studio (sebbene terremo d'occhio questo bug da Paul) :
Questo è successo chiaramente molto tempo fa, ma ho comunque pensato che sarebbe stato interessante condividerlo. Continuiamo ad apportare miglioramenti a Plan Explorer per fornirti le informazioni più accurate possibili e condividerò alcune altre di queste pepite nei prossimi post.
