Złe szacunki kardynalności pochodzące z planów wykonania SSMS

Chciałbym podziękować kilku osobom za ostatnią aktualizację programu SQL Sentry Plan Explorer. Brooke Philpott (@Macromullet) i Greg Gonzalez (blog | @SQLsensei), oczywiście za badania i rozwój oraz za zagłębienie się w kod i uporządkowanie go. Ale także dla Paula White'a (blog | @SQL_kiwi) za wytrwałość w pomaganiu nam w walidacji poprawek.

Problem, który wykrył Paul, polega na tym, że SQL Server 2008+ zaburza oszacowania kardynalności w przypadku niektórych zapytań, gdy zaangażowane są wyszukiwania kluczy lub identyfikatorów RID. Zostawię głębsze wyjaśnienie wpisowi na blogu Paula i błędowi, który zgłosił na Connect, ale krótko mówiąc, wzięliśmy te nieprawdziwe szacunki, uwierzyliśmy im i ekstrapolowaliśmy je, aby pokazać „lepsze” informacje. Niestety, jak wyjaśnia Paul, zostaliśmy oszukani.

Paul pokazuje następujące zapytanie w odniesieniu do kopii AdventureWorks 2005.

SELECT
    th.ProductID,
    th.TransactionID,
    th.TransactionDate
FROM Production.TransactionHistory AS th 
WHERE 
    th.ProductID = 1 
    AND th.TransactionDate BETWEEN '20030901' AND '20031231';

Management Studio daje następujący plan, tak jak to opisał Paul:

W Eksploratorze planów staraliśmy się być pomocni, mnożąc szacowaną liczbę wierszy (w zaokrągleniu do 17) przez liczbę wykonań (45) i otrzymaliśmy 765:

W przypadku większości operatorów to podejście zapewnia prawidłowe dane, ale z powodu tego błędu w programie SQL Server nie jest poprawne w przypadku wyszukiwania kluczy/RID. Dostosowaliśmy to i wydaliśmy odpowiednią poprawkę w 7.2.42.0 (pobierz ją teraz!). Plan graficzny teraz poprawnie pokazuje prawidłową liczbę wierszy dla obu szacowanych:

I aktualne:

Powtórzę ostrzeżenie Pawła:Uważaj na słabe oszacowania kardynalności, gdy orzeczenie jest stosowane jako część wyszukiwania.

W wyniku tych mylących szacunków pojawiły się bardziej złożone problemy, którymi również się zajęliśmy. O kilku z nich napiszę w kolejnym poście – w tym poście chciałem tylko pokazać, że szybko rozwiązaliśmy konkretny problem, który Paul podkreślił w swoim poście.