Ponad trzy lata temu pisałem o poprawce w Eksploratorze planów dotyczącej złych szacunków kardynalności, które generował SQL Server Showplan XML, w przypadku wyszukiwania kluczy/RID z predykatem filtru w SQL Server 2008 i nowszych wersjach. Pomyślałem, że ciekawie byłoby spojrzeć wstecz i bardziej szczegółowo omówić jeden z tych planów i iteracje, przez które przeszliśmy, aby upewnić się, że wyświetlamy prawidłowe metryki, niezależnie od tego, co pokazuje Management Studio. Ponownie, ta praca została w dużej mierze wykonana przez Brooke Philpott (@MacroMullet) i Grega Gonzaleza (@SQLsensei) i przy dużym udziale Paula White'a (@SQL_Kiwi).
Jest to dość podobne do zapytania, które przedstawiłem we wcześniejszym poście, które pochodziło od Paula (i którego odtworzenie dokładnie we współczesnych wersjach AdventureWorks wymagałoby trochę pracy, w których zmieniły się przynajmniej daty transakcji):
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'; Plan z Management Studio wyglądał wystarczająco poprawnie:
Jeśli jednak przyjrzysz się bliżej, wydaje się, że ShowPlan przesunął szacowaną liczbę egzekucji z wyszukiwania klucza bezpośrednio do szacowanej liczby wierszy do ostatecznej wymiany:
Na pierwszy rzut oka diagram planu graficznego w Eksploratorze planów wygląda dość podobnie do planu tworzonego przez SSMS:
Teraz, w trakcie opracowywania Eksploratora Planu, odkryliśmy kilka przypadków, w których ShowPlan nie do końca radzi sobie z matematyką. Najbardziej oczywistym przykładem są wartości procentowe sumujące się do ponad 100%; robimy to dobrze w przypadkach, gdy SSMS jest śmiesznie wyłączony (widuję to dziś rzadziej niż kiedyś, ale nadal się to zdarza).
Innym przypadkiem jest sytuacja, w której, począwszy od SQL Server 2008, SSMS zaczął umieszczać łącznie szacowane wiersze zamiast wierszy na wykonanie wraz z wyszukiwaniami, ale tylko w przypadkach, gdy predykat jest wypychany do wyszukiwania (tak jak w przypadku tego błędu zgłoszonego przez Paula, i ta nowsza obserwacja Joeya D'Antoniego). We wcześniejszych wersjach programu SQL Server (oraz z funkcjami i buforami) zwykle wyświetlaliśmy szacowaną liczbę wierszy wychodzących z wyszukiwania, mnożąc szacowane wiersze na wykonanie (zwykle 1) przez szacowaną liczbę wierszy zgodnie z SSMS. Ale po tej zmianie przeliczylibyśmy, ponieważ operator już teraz wykonuje tę matematykę. Tak więc we wcześniejszych wersjach Eksploratora planów, w porównaniu z rokiem 2008+, można było zobaczyć te szczegóły w etykietkach narzędzi, liniach łączników lub w różnych siatkach:
(Skąd pochodzi 1721? 67,5 szacunkowych egzekucji x 25,4927 szacunkowych wierszy).
W 2012 roku naprawiliśmy część tego problemu, nie wykonując już tej operacji matematycznej i polegając wyłącznie na szacowanej liczbie wierszy pochodzących z wyszukiwania klucza. To było prawie poprawne, ale nadal polegaliśmy na szacowanej liczbie wierszy, które ShowPlan dostarczył nam do ostatecznej wymiany:
Szybko rozwiązaliśmy również ten problem w wersji 7.2.42.0 (wydanej w Hallowe'en 2012) i teraz wydaje nam się, że dostarczamy informacje, które są znacznie dokładniejsze niż Management Studio (chociaż będziemy mieć oko na ten błąd od Paula) :
Stało się to wyraźnie dawno temu, ale nadal uważałem, że warto się podzielić. Nieustannie wprowadzamy ulepszenia w Eksploratorze planów, aby zapewnić Ci jak najdokładniejsze informacje. W nadchodzących postach podzielę się kilkoma z tych samorodków.
