Podczas diagnozowania zapytań SQL Server 2008 R2 ze słabym oszacowaniem liczności (pomimo prostego indeksowania, aktualnych statystyk itp.), A zatem słabymi planami zapytań, znalazłem być może powiązany artykuł KB: POPRAWKA: Niska wydajność po uruchomieniu zapytania który zawiera skorelowane predykaty AND w SQL Server 2008 lub SQL Server 2008 R2 lub SQL Server 2012
Mogę zgadnąć, co artykuł KB oznacza „skorelowany”, np. Predykat nr 2 i predykat nr 1 w dużej mierze są ukierunkowane na te same wiersze.
Ale nie wiem, skąd SQL Server wie o tych korelacjach. Czy tabela potrzebuje indeksu wielokolumnowego zawierającego kolumny z obu predykatów? Czy SQL używa statystyk do sprawdzenia, czy wartości z jednej kolumny są skorelowane z inną? Czy jest używana inna metoda?
Proszę o to z dwóch powodów:
- aby ustalić, które z moich tabel i zapytań można poprawić za pomocą tej poprawki
- wiedzieć, co powinienem zrobić w indeksowaniu, statystykach itp., aby wpłynąć na # 1
źródło
Statistics objects on multiple columns also store statistical information about the correlation of values among the columns
Odpowiedzi:
Rozważ prosty plan zapytania i wykonania AdventureWorks przedstawiony poniżej. Zapytanie zawiera predykaty związane z
AND
. Szacunkowa liczność optymalizatora wynosi 41 211 wierszy:Korzystanie z domyślnych statystyk
Biorąc pod uwagę tylko statystyki jednokolumnowe, optymalizator dokonuje tego oszacowania, szacując liczność dla każdego predykatu osobno i mnożąc wynikowe selektywności razem. Ta heurystyka zakłada, że predykaty są całkowicie niezależne.
Podział zapytania na dwie części ułatwia obliczenia:
Tabela Historia transakcji zawiera łącznie 113 443 wierszy, więc oszacowanie 68 336,4 stanowi selektywność 68336,4 / 113443 = 0,60238533 dla tego predykatu. Oszacowanie to jest uzyskiwane przy użyciu informacji histogramu dla
TransactionID
kolumny i stałych wartości określonych w zapytaniu.Ten predykat ma oszacowaną selektywność na poziomie 68413.0 / 113443 = 0,60306056 . Ponownie jest on obliczany na podstawie stałych wartości predykatu i histogramu
TransactionDate
obiektu statystycznego.Zakładając, że predykaty są całkowicie niezależne, możemy oszacować selektywność dwóch predykatów razem, mnożąc je razem. Ostateczna ocena liczności jest uzyskiwana przez pomnożenie wynikowej selektywności przez 113 443 wierszy w tabeli podstawowej:
Po zaokrągleniu jest to 41 211 danych szacunkowych widocznych w pierwotnym zapytaniu (optymalizator używa również matematyki zmiennoprzecinkowej wewnętrznie).
Niezbyt dobre oszacowanie
TransactionID
ITransactionDate
kolumny mają ścisły związek w danych AdventureWorks zestaw (jak monotonicznie rosnących kluczy i kolumny dat często robią). Korelacja ta oznacza naruszenie założenia niezależności. W rezultacie plan zapytań po wykonaniu zawiera 68 095 wierszy zamiast szacowanych 41 211:Flaga śledzenia 4137
Włączenie tej flagi śledzenia zmienia heurystykę używaną do łączenia predykatów. Zamiast zakładać całkowitą niezależność, optymalizator uważa, że selektywność dwóch predykatów jest na tyle bliska, że można je skorelować:
Przypomnijmy, że
TransactionID
sam predykat oszacował 68 336,4 wierszy, aTransactionDate
sam predykat oszacował 68 413 wierszy. Optymalizator wybrał niższą z tych dwóch wartości szacunkowych zamiast pomnożyć selektywności.Jest to oczywiście inna heurystyka, ale taka, która może pomóc poprawić oszacowania dla zapytań o skorelowanych
AND
predykatach. Każdy predykat jest brany pod uwagę pod kątem możliwej korelacji i dokonano innych korekt, gdy wAND
grę wchodzi wiele klauzul, ale ten przykład służy do pokazania jego podstaw.Statystyka wielokolumnowa
Mogą one pomóc w zapytaniach z korelacjami, ale informacje o histogramie nadal opierają się wyłącznie na wiodącej kolumnie statystyk. Poniższe statystyki kandydatów na wiele kolumn różnią się zatem w istotny sposób:
Biorąc tylko jeden z nich, widzimy, że jedyną dodatkową informacją są dodatkowe poziomy gęstości „wszystkiego”. Histogram nadal zawiera tylko szczegółowe informacje o
TransactionDate
kolumnie.Po wprowadzeniu tych wielokolumnowych statystyk ...
... plan wykonania pokazuje oszacowanie, które jest dokładnie takie samo jak wtedy, gdy dostępne były tylko statystyki z jedną kolumną:
źródło