it-swarm.dev

Jak ustalić, czy Indeks jest wymagany czy konieczny

Uruchomiłem narzędzie autoindeksowania w naszej bazie danych MS SQL (zmodyfikowałem skrypt pochodzący od Microsoft, który przegląda tabele statystyk indeksu - automatyczne indeksowanie automatyczne ). Ze statystyk mam teraz listę rekomendacji dla indeksów, które wymagają utworzenia.

Edycja: Indeksy opisane powyżej pobierają informacje z DMV, które informują o tym, czego silnik bazy danych użyłby do indeksów, gdyby były dostępne, oraz skrypty biorą rekomendacje Top x (według poszukiwań, wpływu użytkownika itp.) i umieszczają je w tabeli.

(Edycja powyżej częściowo pochodzi z poniższej odpowiedzi Larry'ego Colemana, aby wyjaśnić, co robią skrypty)

Ponieważ jestem nowy w administrowaniu bazami danych i po szybkim przeszukaniu sieci, niechętnie podejmuję decyzję i ślepo dodaje zalecane indeksy. Jednak nie mając doświadczenia w tej dziedzinie, szukam porady, jak ustalić, czy zalecenia są konieczne, czy nie.

Czy muszę uruchomić SQL Profiler, czy też lepiej jest sprawdzić kod, który wysyła zapytania do tabel? Czy masz jakieś inne rady?

112
misterjaytee

Używam skrypty analizy indeksu Jasona Strate'a (stara lokalizacja) . Informują o tym, ile wykorzystano istniejących indeksów, a także ile wykorzystano by brakujących indeksów. Zazwyczaj nie dodam indeksów, chyba że stanowią one więcej niż 5 lub 10% zapytań w tabeli.

Najważniejsze jest jednak zapewnienie, aby aplikacja reagowała wystarczająco szybko dla użytkowników.

Aktualizacja: Artykuły na blogu poświęcone analizie indeksu Jason Strate dotyczące nowszych skryptów (Nowa lokalizacja)

Podwójna aktualizacja: Obecnie używam sp_BlitzIndex® podczas analizy indeksu.

81

Istnieje kilka pojęć i terminów, które należy zrozumieć, posługując się indeksami. Wyszukiwanie, skanowanie i wyszukiwanie to tylko niektóre ze sposobów wykorzystania indeksów za pomocą instrukcji select. Selektywność kluczowych kolumn jest integralną częścią określania skuteczności indeksu.

Wyszukiwanie ma miejsce, gdy Optymalizator kwerend programu SQL Server ustali, że najlepszym sposobem na znalezienie danych, o które prosiłeś, jest skanowanie zakresu w obrębie indeksu. Wyszukiwanie zwykle ma miejsce, gdy zapytanie jest „objęte” indeksem, co oznacza, że ​​predykaty wyszukiwania znajdują się w kluczu indeksu, a wyświetlane kolumny są albo w kluczu, albo włączone. Skanowanie ma miejsce, gdy Optymalizator kwerend programu SQL Server ustali, że najlepszym sposobem na znalezienie danych jest skanowanie całego indeksu, a następnie filtrowanie wyników. Wyszukiwanie zwykle występuje, gdy indeks nie obejmuje wszystkich żądanych kolumn, ani w kluczu indeksu, ani w uwzględnionych kolumnach. Optymalizator zapytań użyje następnie klucza klastrowego (w stosunku do indeksu klastrowego) lub RID (w stosunku do sterty), aby „przeszukać” pozostałe żądane kolumny.

Zwykle operacje wyszukiwania są bardziej wydajne niż skanowanie, ponieważ fizycznie wykonują zapytania do mniejszego zestawu danych. Są sytuacje, w których tak nie jest, na przykład bardzo mały początkowy zestaw danych, ale wykracza to poza zakres pytania.

Teraz zapytałeś, jak określić, jak skuteczny jest indeks, i należy pamiętać o kilku kwestiach. Kolumny klucza indeksu klastrowego nazywane są kluczem klastrowym. W ten sposób rekordy są unikalne w kontekście indeksu klastrowego. Wszystkie indeksy nieklastrowane będą domyślnie zawierać klastrowany klucz, aby w razie potrzeby wyszukiwać. Wszystkie indeksy zostaną wstawione, zaktualizowane lub usunięte z każdej odpowiedniej instrukcji DML. To powiedziawszy, najlepiej zbilansować wzrost wydajności w wybranych instrukcjach z uderzeniami wydajności w instrukcjach wstawiania, usuwania i aktualizacji.

Aby określić skuteczność indeksu, należy określić selektywność kluczy indeksu. Selektywność można zdefiniować jako procent odrębnych rekordów w stosunku do rekordów ogółem. Jeśli mam tabelę [osoba] zawierającą 100 rekordów, a kolumna [imię] zawiera 90 różnych wartości, możemy powiedzieć, że kolumna [imię] jest selektywna w 90%. Im wyższa selektywność, tym bardziej wydajny jest klawisz indeksu. Pamiętając o selektywności, najlepiej umieścić swoje najbardziej selektywne kolumny na pierwszym miejscu w kluczu indeksu. Korzystając z mojego poprzedniego przykładu [person], co gdybyśmy mieli kolumnę [nazwisko], która była w 95% selektywna? Chcielibyśmy utworzyć indeks z [last_name], [first_name] jako kluczem indeksu.

Wiem, że była to dość długa odpowiedź, ale tak naprawdę jest wiele rzeczy, które decydują o skuteczności indeksu, i wiele rzeczy, z którymi musisz się liczyć, jeśli chodzi o wzrost wydajności.

51
Matt M

Niedawno odkryłem fantastyczny darmowy skrypt od ludzi z BrentOzar Unltd http://www.brentozar.com/blitzindex/

Robi to dobrą analizę tego, które indeksy istnieją, jak często są one używane i jak często silnik zapytań szuka indeksu, który nie istnieje.

Jego wskazówki są ogólnie dobre. Czasami robi się to zbyt przesadne. Do tej pory ogólnie zrobiłem następujące:

  • Usunięto indeksy, które NIGDY nie były czytane (a może mniej niż 50 razy w miesiącu).
  • Dodano najbardziej oczywiste indeksy dotyczące kluczy obcych i pól, o których wiem, że dużo używamy.

Nie dodałem wszystkich zalecanych indeksów i wróciłem tydzień później, aby stwierdzić, że nie są one już zalecane, ponieważ silnik zapytań używa innych nowych indeksów!

Zasadniczo należy unikać indeksowania:

  • Bardzo małe tabele (mniej niż 50 do 200 rekordów): często silnik zapytań jest szybszy, jeśli skanuje tabelę, zamiast ładować indeks, czytać, przetwarzać itp.
  • Unikaj indeksów dla kolumn o niskiej liczności ( http://en.wikipedia.org/wiki/Cardinality_ (SQL_statements) ) w pierwszej wspomnianej kolumnie. Na przykład. Indeksowanie pola płci (M/K) jest bardzo mało przydatne, równie praktyczne jest zeskanowanie tabeli i znalezienie ~ 50% pasujących. Jeśli jest wymieniony po czymś bardziej szczegółowym w indeksie (np. [Data urodzenia, płeć]), to lepiej - możesz chcieć, aby wszyscy mężczyźni urodzili się w określonym przedziale czasu.

Indeksy klastrowe są dobre - zwykle są oparte na kluczu podstawowym. Pomagają silnikowi bazy danych porządkować dane na dysku w odpowiedniej kolejności. Jest to bardzo istotne, aby zrozumieć to w przypadku największych tabel, ponieważ dobry indeks klastrowy często zmniejsza przestrzeń zajmowaną przez tabelę.

Zmniejszyłem niektóre tabele z 900 MB do 400 MB, tylko dlatego, że wcześniej były to niezliczone stosy. http://msdn.Microsoft.com/en-us/library/aa933131 (v = sql.80) .aspx

Reorganizuj/Odbuduj

Powinieneś szukać pofragmentowanych indeksów. Trochę fragmentacji jest w porządku, nie bądź obsesyjny! http://technet.Microsoft.com/en-us/library/ms189858.aspx Poznaj różnicę między reorganizacją a przebudową!

Regularnie sprawdzaj

Zapytania zmieniają się, zmieniają się ilości danych, nowe funkcje są dodawane, stare usuwane. Powinieneś patrzeć na nie raz w miesiącu (lub częściej, jeśli masz dużo woluminów) i szukać, gdzie możesz pomóc bazie danych!

Ile

W ostatnim filmie Brent zaleca (zwykle) nie więcej niż 5 indeksów na stole z dużą ilością zapisów (np. Tabela zamówień) i nie więcej niż 10, jeśli jest czytany o wiele więcej niż napisany (tj. Tabela rejestrowania dla analiz) http://www.youtube.com/watch?v=gOsflkQkHjg

Ogólnie

To zależy!

Twój przebieg różni się w zależności od bazy danych. Obejmuj oczywiste (nazwisko pracownika, data zamówienia itp.) Na twoich (teraz/w przyszłości) większych tabelach. Monitoruj, przeglądaj i dostosowuj w razie potrzeby. Powinien być częścią rutynowej listy kontrolnej podczas zarządzania bazą danych :)

Mam nadzieję że to pomoże!

29
Greg Robson

Zwykle stosuje się określone obciążenie (zapytania) i dokładnie testuje wpływ każdego nowego indeksu na obciążenie. Ten iteracyjny proces powinien zawsze obejmować staranną analizę planów wykonania, która ujawniłaby, jakie indeksy są używane. Temat analizy zapytania jest długi, a dobrym pomysłem jest rozpoczęcie od dedykowanego rozdziału MSDN Analiza zapytania .

Czasami, gdy obciążenie jest zbyt złożone lub wiedza na temat projektu bazy danych jest pobieżna, używa się Doradca dostrajania aparatu bazy danych , który dokonuje automatycznej analizy obciążenia i proponuje pewne wskaźniki. Wnioski należy oczywiście dokładnie przeanalizować, a wpływ należy natychmiast zmierzyć.

Więc jeśli zastosujesz się do mojego pomysłu, dodanie indeksu i zmierzenie wpływu jest tak naprawdę tylko przypadkiem testowanie A/B : uruchamiasz obciążenie bez indeksu jako linię bazową, a następnie uruchamiasz go z indeksem zmierzyć i porównać z linią bazową, a następnie zdecydować, na podstawie zaobserwowanych i zmierzonych wskaźników, czy wpływ jest korzystny. Obciążenie jest najlepszym zestawem testowym dobrej jakości, ale może być także powtórką przechwyconego obciążenia, patrz Jak: odtworzyć plik śledzenia .

Bardziej syntetyczną odpowiedzią jest spojrzenie na sys.dm_db_index_usage_stats wyświetl i zobacz, w jaki sposób wykorzystywane są indeksy, ale jest to zwykle podejście do przeprowadzania analizy na miejscu przy nieznanym obciążeniu pracą (tj. konsultant wezwany do pomocy prawdopodobnie zacznie od tego).

14
Remus Rusanu

Począwszy od SQL 2005, SQL Server ma DMV , które mówią ci, czego silnik bazy danych użyłby do indeksów, gdyby były one dostępne. Widoki pokazują, które kolumny powinny być kluczowymi kolumnami, które kolumny powinny zostać uwzględnione, a co najważniejsze, ile razy indeks byłby użyty.

Dobrym rozwiązaniem byłoby posortowanie brakującego zapytania o indeksy według liczby wyszukiwań i rozważenie dodania najpierw najlepszych indeksów.

Zobacz także: oficjalne dokumenty MS DMV

8
Larry Coleman