Niska wydajność zapytań


10

Mamy dużą procedurę (ponad 10 000 linii), która zwykle trwa od 0,5 do 6,0 sekund w zależności od ilości danych, z którymi musi współpracować. W ciągu ostatniego miesiąca zaczęło to zabierać ponad 30 sekund po aktualizacji statystyk za pomocą FULLSCAN. Kiedy zwalnia, sp_recompile „naprawia” problem, dopóki zadanie statystyki nocnej nie uruchomi się ponownie.

Porównując powolne i szybkie plany wykonania, zawęziłem go do konkretnej tabeli / indeksu. Gdy działa wolno, szacuje się, że ~ 300 wierszy zostanie zwróconych z określonego indeksu, a gdy działa szybko, szacuje 1 wiersz. Gdy działa wolno, używa buforowania tabeli po przeszukiwaniu indeksu, a gdy działa szybko, nie wykonuje buforowania tabeli.

Używając DBSS SHOW_STATISTICS, wykreśliłem histogram indeksu w programie Excel. Normalnie oczekiwałbym, że wykres będzie bardziej „toczącymi się wzgórzami”, ale zamiast tego wygląda jak góra, a najwyższy punkt jest 2x-3x wyższy niż większość innych wartości na wykresie.

Histogram indeksu

Jeśli zaktualizuję statystyki, bez FULLSCAN, wygląda to bardziej normalnie. Jeśli następnie uruchomię go ponownie z FULLSCAN, wygląda to tak, jak opisano powyżej.

Wydaje się, że jest to kwestia wąchania parametrów i szczególnie związana z (pozornie) dziwnym rozkładem indeksu powyżej.

Proc przyjmuje parametr wyceniony w tabeli, czy wąchanie parametru może wystąpić w przypadku parametru wycenionego w tabeli?

EDYCJA: Proc ma również 12 innych parametrów, z których niektóre są opcjonalne, z których dwa są datą początkową i końcową.

Czy histogram jest dziwny, czy szczekam na niewłaściwym drzewie?

Z pewnością czuję się dobrze, próbując dostosować zapytanie i / lub próbować dostosować moje indeksowanie. Jeśli taka poprawka jest świetna, w tym momencie moje pytanie dotyczy raczej wypaczonego histogramu.

Powinienem wspomnieć, że jest to klastrowany indeks PK IDENTITY. Mamy dwa systemy, które ze sobą rozmawiają, jeden starszy, drugi nowy, domowy. Oba systemy przechowują podobne dane. Aby je zsynchronizować, PK na tej tabeli w nowym systemie jest zwiększane, gdy elementy są dodawane do starego systemu, nawet jeśli dane nie zostaną przesłane (wykonano RESEED). Mogą występować luki w numeracji w tej kolumnie. Rekordy są rzadko, jeśli w ogóle, usuwane.

Jakiekolwiek propozycje będą mile widziane. Z przyjemnością gromadzę / dołączam więcej informacji.


Czy jedynym parametrem procedury jest TVP, czy też są też inne parametry?
Martin Smith

1
Jeśli spojrzysz na powolny i szybki plan XML, czy różnica byłaby zrozumiała przez inne ParameterCompiledValuedla tych innych parametrów?
Martin Smith

1
Zakres dat, z którym się skompilował, jest znacznie węższy (5 dni zamiast 31). W przypadku większości połączeń ten proces będzie działał przez miesiąc. Mógłbym spróbować dodać wskazówkę dotyczącą ponownej kompilacji do tej konkretnej instrukcji.
Mark Wilkinson

1
To zdecydowanie wydaje się dziwnym rozkładem dla kolumny tożsamości. Właśnie czytałem ten artykuł i zastanawiałem się, czy możesz rozwinąć to, co widzisz dla tych dwóch planów w porównaniu z rzeczywistością? > blogs.technet.com/b/mspfe/archive/2013/04/18/…
Richard Schweiger

1
Żeby było jasne: na czym dokładnie polega wykres? RANGE_HI_KEYprzypuszczalnie na osi x, ale co na osi y? EQ_ROWS? RANGE_ROWS? Suma tych?
Paul White 9

Odpowiedzi:


3

Skończyło się to powiązaniem z wąchaniem parametrów. Tak się złożyło, że niektóre dziwnie sformułowane wersje tego zapytania były wykonywane PRAWO PO przebudowaniu statystyk. Zatem buforowany plan nie był reprezentatywny dla większości połączeń. Wykorzystałem sztuczkę polegającą na skopiowaniu parametrów daty do zmiennych lokalnych i działa to dobrze, bez wpływu na wydajność. To nie wyjaśnia, dlaczego histogram wygląda na „wyłączony”, ale wyjaśnia moje problemy z wydajnością.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.