Pięć najważniejszych kwestii dotyczących projektowania indeksu bazy danych w programie SQL Server

Indeksy bazy danych służą do przyspieszenia różnych operacji na tabelach. Jednak zanim utworzysz indeks, ważne jest, aby wiedzieć, czy naprawdę potrzebujesz indeksu? A jeśli musisz stworzyć indeks, jakie są ważne punkty, o których należy pamiętać? W tym miejscu pojawia się projekt indeksu bazy danych.

Ten artykuł ma na celu odpowiedzieć na te pytania dotyczące projektowania indeksów baz danych i rzucić nieco światła na niektóre z głównych kwestii, które programista baz danych powinien wziąć pod uwagę podczas projektowania indeksu.

1. Rozmiar stołu

Pierwszym pytaniem, które programista bazy danych musi zadać przed utworzeniem indeksu, jest to, czy tabela jest wystarczająco duża, aby efektywnie korzystać z indeksów. Jeśli rozmiar tabeli jest mały, silnik SQL Server może przeskanować całą tabelę szybciej niż przeszukiwanie tabeli przez indeks. Indeksy w takim przypadku są bezużyteczne i powodują narzut podczas wykonywania operacji na bazie danych.

2. Typy kolumn

Indeksy powinny być tworzone w kolumnie klucza podstawowego lub dowolnej kolumnie zawierającej unikatowe wartości i mającej ograniczenie NOT NULL. Ponadto zaleca się tworzenie indeksów na kolumnach numerycznych, ponieważ kolumny numeryczne mają zwykle więcej unikalnych wartości w porównaniu z kolumnami nienumerycznymi. Słaby projekt indeksu bazy danych wykorzystuje indeksy w kolumnach, które mają bardzo mało unikalnych wpisów i mogą skutkować bardzo czasochłonnymi zapytaniami.

Rozważ tabelę Pacjenci, która zawiera setki tysięcy rekordów. Tabela Pacjenci zawierałaby kolumnę o nazwie „Płeć”, która może mieć tylko dwie unikalne wartości „Mężczyzna” i „Kobieta”. Jeśli utworzysz indeks w „Kolumnie Płeć”, rekordy zostaną posortowane w rosnącej lub malejącej kolejności alfabetycznej.

Jeśli więc masz milion rekordów w tabeli Pacjenci, a liczba pacjentów płci męskiej i żeńskiej jest równa, w indeksie pierwsze pół miliona rekordów będzie miało płeć „Kobieta”, a drugie pół miliona będzie miało płeć „Mężczyzna”. Teraz, jeśli chcesz wyszukać kobietę, która istnieje w 490 000 wierszu rekordów żeńskich, silnik SQL Server będzie musiał przeskanować 490000 rekordów. Z drugiej strony, dzięki unikalnym wartościom liczbowym, wyszukiwanie może być niezwykle szybkie, ponieważ indeksy SQL Server są przechowywane w postaci B + Trees, a więc wartości liczbowe w węzłach drzewa mogą przyspieszyć operacje na bazie danych.

3. Liczba indeksów

Oficjalnie można utworzyć jeden indeks klastrowy i dowolną liczbę indeksów nieklastrowych dla każdej tabeli bazy danych. Jednak dobrym projektem indeksu bazy danych jest utworzenie jednego indeksu klastrowego i tylko ograniczonej liczby absolutnie niezbędnych indeksów nieklastrowych. Tworzenie zbyt wielu indeksów nieklastrowych może w rzeczywistości spowolnić operacje Update i Insert, ponieważ po zaktualizowaniu lub wstawieniu rekordu i zmianie wartości kolumny wszystkie skojarzone indeksy muszą zostać zaktualizowane.

Rozważmy scenariusz, w którym mamy dwa indeksy nieklastrowe, pierwszy indeks sortuje rekordy według wieku, a drugi indeks sortuje rekordy zarówno według płci, jak i wieku.

Oto pierwszy indeks:

A oto drugi:

Teraz, jeśli z jakiegoś powodu rekord z 40 rokiem życia musi zostać zaktualizowany do wieku 15 lat, to pierwszy indeks będzie musiał zostać zaktualizowany, aby przenieść rekord z 7. pozycji (40) na drugą pozycję, aby indeks był posortowany. Podobnie w indeksie drugim, rekord z indeksu czwartego zostanie przeniesiony do indeksu drugiego. Musi nastąpić wiele przetasowań. Dlatego dobrze jest ograniczyć liczbę indeksów do minimum dla kolumn, które są regularnie aktualizowane, myśląc o projekcie indeksu bazy danych. Również jedna kolumna nie powinna być używana w wielu indeksach nieklastrowanych.

4. Miejsce przechowywania indeksów

Miejsce przechowywania indeksu może wpływać na wydajność zapytań korzystających z indeksu, a zatem jest również częścią dobrego projektu indeksu bazy danych. Domyślnie indeks klastrowany jest przechowywany w tej samej grupie plików, co tabela, w której tworzony jest indeks. W przypadku indeksów nieklastrowanych indeks może być przechowywany w tej samej grupie plików lub w różnych grupach plików obejmujących wiele dysków. Wydajność zapytań indeksów nieklastrowanych można znacznie poprawić, przechowując indeksy nieklastrowane na wielu dyskach. Dzieje się tak, ponieważ wydajność wejścia/wyjścia zapytania zostanie poprawiona w wyniku dystrybucji danych w różnych obszarach dysku.

Domyślną lokalizację przechowywania indeksów można również zmienić, określając wartość opcji FILLFACTOR. Ponieważ indeksy są fizycznie przechowywane w postaci B+ Trees, dane indeksowe są przechowywane na stronach liści. Za pomocą opcji FILLFACTOR możesz ustawić procent wypełnienia stron na poziomie liścia. Na przykład, jeśli ustawisz wartość FILLFACTOR na 70%, tylko 70% całkowitej przestrzeni strony na poziomie liścia zostanie wypełnione danymi indeksu. Pozostałe 30% zostanie w przyszłości na automatyczny wzrost danych indeksowych.

5. Typy indeksów

Inną niezwykle ważną kwestią przy projektowaniu indeksu bazy danych jest typ indeksu, którego należy użyć. We wcześniejszym artykule (dodaj link do artykułu „Kiedy używać indeksu klastrowego lub nieklastrowego”) wyjaśniłem różnicę między indeksami klastrowymi i nieklastrowymi. Wyjaśniłem też, czym są i jak można z nich korzystać. Decyzja, czy wybrać indeks klastrowy, czy nieklastrowy, jest kluczowa i powinna być dokładnie przemyślana.

Przy podejmowaniu decyzji o wyborze rodzaju indeksu należy pamiętać o następujących kwestiach.

1. Dla kolumn używanych w zapytaniach SELECT/JOIN/GROUP BY/BETWEEN użyj indeksów klastrowych.
2. Użyj indeksów nieklastrowanych dla kolumn, w których chcesz pobrać wartości tylko z tej konkretnej kolumny, a nie z innych kolumn tego samego wiersza. Zapytania SELECT pobierające wiele rekordów przy użyciu indeksu nieklastrowego mogą być powolne, ponieważ silnik SQL Server najpierw przeszukuje wartości kolumn, dla których tworzony jest indeks, a następnie przy użyciu odwołania do wiersza dla wartości kolumny pobierane są rekordy z rzeczywistych tabel bazy danych .
3. W przypadku kolumn, które często przechodzą operacje INSERT i UPDATE, użyj indeksu nieklastrowego. Upewnij się, że nie używasz jednej kolumny w wielu indeksach nieklastrowanych, ponieważ może to spowolnić zapytania aktualizacyjne. Indeksy klastrowane mogą być powolne w przypadku operacji INSERT/UPDATE, ponieważ należy zaktualizować cały wiersz, a nie tylko wartość pojedynczej kolumny, jak ma to miejsce w przypadku indeksów nieklastrowanych.
4. Ponieważ można utworzyć tylko jeden indeks klastrowany, w ich przypadku, gdy potrzebujesz wielu indeksów, użyj indeksów nieklastrowych. Jeśli jednak miejsce na dysku jest głównym problemem, należy ograniczyć liczbę indeksów nieklastrowanych do minimum.

Inne uwagi

Chociaż jest to pięć najważniejszych elementów projektowania indeksów baz danych, to nie wszystko. Ważne jest, aby określić poprawną kolejność kolumn w indeksach. Zasadniczo kolumny używane do podejmowania decyzji w klauzulach WHERE oraz warunki, takie jak większe niż (>), mniejsze niż (<) itp., należy umieszczać przed kolumnami, które nie są objęte tymi klauzulami. W przypadku wielu kolumn w klauzuli WHERE, najbardziej charakterystyczne nazwy kolumn powinny być wymienione najwcześniej w definicji indeksu.

Oprócz projektowania indeksów baz danych, projektowanie zapytań odgrywa również ważną rolę w efektywnym wykorzystaniu projektowania indeksów. Aby zoptymalizować konserwację indeksu, zamiast pisać wiele zapytań, które działają na małej liczbie wierszy, spróbuj napisać mniej zapytań, które wpływają na większą liczbę wierszy tabeli.

Wniosek

W tym artykule wyjaśniono niektóre z głównych kwestii, które programista baz danych musi wziąć pod uwagę, patrząc na projekt indeksu bazy danych. Artykuł wyjaśnia również uzasadnienie tych rozważań i zawiera dalsze sugestie, aby upewnić się, że projekt indeksu bazy danych jest wydajny.