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

Edycja: Indeksy opisane powyżej pobierają informacje z DMV, które mówią ci, co silnik bazy danych użyłby do indeksów, gdyby były one dostępne, a skrypty przyjmują rekomendacje Top x (przez próby, wpływ 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ę decyzje i ślepo dodaje zalecane indeksy. Nie mając jednak 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 przeszukuje tabele? Czy masz jakieś inne rady?

Używam skryptów analizy indeksów 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ą 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ęconym analizie indeksu Jason Strate dotyczące nowych skryptów (Nowa lokalizacja)

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

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 niezbędna do określenia skuteczności indeksu.

Wyszukiwanie ma miejsce, gdy Optymalizator kwerend programu SQL Server ustali, że najlepszym sposobem na znalezienie żądanych danych jest skanowanie zakresu w ramach 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ć skuteczność indeksu, i musisz 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ć klucz klastrowany, 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. Mając na uwadze selektywność, 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 to była 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.

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. Np. Indeksowanie pola płci (M / F) 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 czasowym.

Indeksy klastrowe są dobre - zwykle są oparte na kluczu podstawowym. Pomagają silnikowi bazy danych uporządkować dane na dysku w odpowiedniej kolejności. Jest to bardzo ważne, aby zrozumieć to dla 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ą pisania (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ólny

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!

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, korzysta się z Doradcy 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 to tak naprawdę tylko przypadek testowania A / B : uruchamiasz obciążenie bez indeksu jako linię bazową, a następnie uruchamiasz go z indeksem, mierzysz i porównujesz z linią bazową, a następnie zdecyduj, 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 to być także powtórka przechwyconego obciążenia, zobacz Jak: odtworzyć plik śledzenia .

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

Począwszy od SQL 2005, SQL Server ma DMV -y, które mówią ci, czego mógłby użyć silnik bazy danych dla 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 podejściem 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}

To zależy od tego, jak ten stół jest używany. np. powiedzmy, że mam tabelę, która jest czytana wiele razy, ale aktualizacje i wstawki są rzadkie. Ponadto zawsze przeszukuję tabelę w kolumnie z kluczem obcym. Sensowne będzie utworzenie (nieklastrowanego) indeksu nad tym kluczem obcym, aby przyspieszyć zapytania o odczyt. Ale wadą jest to, że Twoja wstawka, aktualizacja stanie się wolna.

Istnieje kilka zapytań statystycznych, które pokazują, ile czasu zajmuje zapytanie. Zacznij od najwolniejszych. Jeśli predykat zapytania nie ma indeksu, utworzenie go pomoże.