Indeksowanie bazy danych


12

Nie znam się tak dobrze na bazach danych, a teraz próbuję zrozumieć mechanizm indeksowania.

Z tego, co wiem, w RDBMS indeksowanie w kolumnie przyspiesza wyszukiwanie w tej kolumnie. Odnosi się to również do potrójnych sklepów, tylko tam wskaźniki zakładają, że będziesz wyszukiwać (na przykład) głównie według tematu, następnie według obiektu i tak dalej.

Nie jestem pewien co do RDBMS, ale w potrójnych sklepach możesz zdefiniować więcej niż jeden indeks, pozwalając sklepowi wybrać najlepszy indeks dla każdego zapytania (mam nadzieję, że dobrze to zrozumiałem). Oczywiście pojawia się następujące pytanie:

Dlaczego nie powinienem dodawać wszystkich możliwych indeksów do potrójnego sklepu i rozszerzać do RDBMS, dlaczego nie tworzyć indeksów w każdej kolumnie (zakładając, że nie jestem zbyt leniwy)?

Odpowiedzi:


25

Ponieważ w zasadzie indeks jest dodatkową tabelą, w której kluczem podstawowym jest pole, które indeksujesz, a jedyną zawartością jest klucz podstawowy tabeli głównej. Tak więc każdą aktualizację należy replikować w każdym indeksie korzystającym z aktualizowanego pola.

Jest to szczególnie widoczne w przypadku wkładek. Wyobraź sobie, że każda wstawka wykonana w tabeli musiała być replikowana w 20 innych tabelach. Będzie boleśnie powolne.

Zauważ, że jest jeszcze gorzej w przypadku indeksów złożonych, klastrowych i pełnotekstowych, ale nie chcę jeszcze komplikować tego problemu.


2

Indeksy są w zasadzie dodatkowymi strukturami danych, które należy zbudować i przechowywać. Budowanie inde marnuje moc procesora (podczas operacji zapisu), a przechowywanie go marnuje pojemność dysku.

Dlaczego chcesz tworzyć i przechowywać indeksy, których nigdy nie używasz?


Jest to pytanie czysto teoretyczne („co jeśli / dlaczego nie”).
Dragos,

@Dragos Myślę, że odpowiedź na to pytanie jest oczywista z mojego postu: Jeśli tak, każda operacja zapisu byłaby znacznie wolniejsza, a każdy rekord marnowałby dużo miejsca na dysku. Dlaczego nie? Ponieważ moc procesora i pamięć dyskowa są drogie.
Matěj Zábský

2

Indeksy należy umieszczać tylko w razie potrzeby. Jako podstawową zasadę, gdy opracowuję schemat bazy danych, każda tabela otrzymuje na początku indeks klastrowany klucza podstawowego PK. Będzie to unikalny identyfikator danych w tej tabeli. W może znajdować się na 1 kolumnie lub wielu.

Następnie zazwyczaj dodam po prostu niepowtarzalne indeksy nieklastrowane w kolumnach, w których chcę wymusić unikalność.

To jest schemat podstawowy. Gdy aplikacja się rozwija i dojrzewa, w razie potrzeby dodajemy indeksy w oparciu o problemy z wydajnością i sposób, w jaki sprawdzamy dane.

Każdy dodany indeks zwiększa zastosowane odstępy, a także dodaje dodatkową konserwację. Wybierz mądrze swoje indeksy.


Czytając twoją odpowiedź, przyszło mi do głowy kolejne pytanie: czy klucze podstawowe są zwykle automatycznie indeksowane, czy też muszę sam określić, że będą indeksowane? Powiedz na przykład w bazie danych MySQL?
Dragos,

Tak, klucz podstawowy powinien automatycznie utworzyć indeks klastrowy dla (SQL Server). Tylko jeden klucz podstawowy, a więc tylko jeden indeks klastrowy na tabelę. MySQL powinien być podobny, ale może ekspert MySQL może to sprawdzić.
Jon Raynor,

2

Siła indeksów polega na tym, że są one 1) strukturą danych, którą można szybko przeszukać i 2) bardziej zwartą niż rzeczywiste tabele, dzięki czemu więcej indeksu zmieści się w pamięci zamiast być stronicowanym na dysk.

Jeśli masz indeks w każdej kolumnie, wówczas same indeksy zajmą więcej miejsca niż reprezentowana tabela. Jeśli baza danych naprawdę korzysta ze wszystkich indeksów, zajmie to więcej czasu tylko na zamianę ich i brak pamięci. Ponadto każdy indeks musi być aktualizowany w trybie obojętnym, aktualizowanym lub usuwanym.

Poza tym indeksy w jednej kolumnie nie są nawet najlepsze, co możesz zrobić. Większość baz danych relacji pozwala na indeks wielu kolumn, a kolejność tych kolumn ma znaczenie. Na przykład, jeśli chcę przeszukać bazę danych dla wszystkich osób, które uczęszczały do ​​Duke'a z klas między 1980 a 1984 rokiem, to chcę tego indeksu (School, ClassYear). W zapytaniu nie można użyć indeksu z tymi samymi kolumnami, ale odwrócić.

Aby stworzyć każdy możliwy indeks, jest co najmniej n! sposoby układania kolumn w indeksie. Przy zaledwie 5 kolumnach istnieje 120 możliwych indeksów.

Ponieważ istnieje wiele możliwych indeksów, naprawdę musisz ustalić, które indeksy są przydatne dla Twojej aplikacji, i utworzyć tylko te.


Ale czy w twoim przykładzie dwa indeksy: jeden w School i drugi w ClassYear byłyby przydatne w każdym przypadku?
Dragos,

@Dragos Pewnie, że mogą. Gdybym miał inne zapytanie, które dotyczyło tylko roku klasowego (wszyscy uczniowie, którzy chodzili do szkoły w klasie 2004), wówczas indeks roku klasowego może być przydatny. Niestety, przy podejmowaniu decyzji, jakiego indeksu użyć, silnik zapytań ma mnóstwo czynników. Jeśli okaże się, że połowa ludzi w bazie danych nie iść do szkoły w 2004 roku, a następnie baza danych może po prostu zignorować indeks i skanuje całą tabelę jakikolwiek. Jeśli chcesz być w tym dobry, zacznij używać i czytać plany wykonania
Chris Pitman,

Chodziło mi o to, że jeśli mam osobne indeksy dotyczące School i ClssYear, byłyby one przydatne przy poszukiwaniu wszystkich osób, które uczęszczały do ​​Duke z klas w latach 1980–1984?
Dragos,

@Dragos Zależy to od konkretnego silnika db. Na przykład Postgres użyje czegoś o nazwie Skanowanie indeksu bitmap w celu przecięcia wyników wielu indeksów. Mechanizm zapytań decyduje o tym, którego indeksu użyć, a to zawsze będzie zależne od db.
Chris Pitman,

2

Utworzenie indeksu dla każdej kolumny w tabeli jest zwykle stratą miejsca, a jak wspomnieli inni, może spowolnić operacje wstawiania / aktualizacji. Indeks służy do przyspieszenia zapytań. Zalecałbym dodanie indeksu do kolumny tylko wtedy, gdy zauważysz słabą wydajność podczas zapytania o wartości w tej kolumnie.

Niektóre bazy danych mogą wymagać indeksu klucza podstawowego tabeli, więc możesz nie mieć wyboru. Ponadto, jeśli masz bardzo duże kolumny tekstowe, istnieją specjalne technologie, które są zaprojektowane do wyszukiwania pełnotekstowego i indeksowania, ale nie zawsze są to te same rodzaje indeksu, których używasz dla małej kolumny liczbowej.

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.