Niska wydajność zapytań

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.

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.

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ą.