Skąd mam wiedzieć, kiedy indeksować kolumnę i z czym?

W dokumentach dla różnych ORM zawsze zapewniają sposób tworzenia indeksów itp. Zawsze wspominają, aby mieć pewność, że stworzysz odpowiednie indeksy dla wydajności, tak jakby była to wiedza nieodłączna dla nie-ręcznie pisanego-Sqlera, który musi użyć ORM. Moje zrozumienie indeksów (poza PK) jest w zasadzie następujące: jeśli planujesz wykonywać LIKE zapytania (czyli wyszukiwanie) na podstawie zawartości kolumny, powinieneś użyć indeksu pełnotekstowego dla tej kolumny. Co jeszcze powinienem wiedzieć o indeksach (głównie sprawność)? Czuję, że świat wiedzy jest u moich drzwi, ale pod nim jest ogromna składana podkładka pod mysz, więc nie mogę się przez nią przejść (Nie wiem, dlaczego czułem, że muszę to powiedzieć, ale dzięki za dostarczenie kanapy).

Author: orokusaki, 2010-11-04

2 answers

Pomyśl o indeksie bardzo zbliżonym do indeksu z tyłu książki. Jest to całkowicie oddzielny obszar od zawartości książki, gdzie jeśli szukasz jakiejś konkretnej wartości, możesz przejść do indeksu i go wyszukać (indeksy są uporządkowane, więc znalezienie tam rzeczy jest znacznie szybsze niż skanowanie każdej strony książki).

Wpis indeksu ma numer strony, więc możesz szybko przejść do strony szukającej twojego tematu. Indeks bazy danych jest bardzo podobny; jest to uporządkowana lista odpowiednich informacje w bazie danych(pola zawarte w indeksie), z informacjami dla bazy danych, aby znaleźć rekordy, które pasują.

Więc... możesz utworzyć indeks, gdy masz informacje, które musisz często wyszukiwać. Normalne indeksy nie pomagają w przypadku' częściowych ' zapytań typu LIKE, ale za każdym razem, gdy musisz uzyskać zestaw wyników, w których pole X ma określone wartości, DBMS nie musi 'skanować' całej tabeli, szukając pasujących wartości.

Oni również pomóc, gdy trzeba sortować na kolumnie.

Kolejna rzecz, o której należy pamiętać; jeśli DBMS pozwala na tworzenie pojedynczych indeksów, które mają wiele pól, pamiętaj, aby zbadać efekty tego działania, specyficzne dla Twojego DBMS. Indeks zawierający wiele pól może być w pełni (lub w ogóle) użyteczny tylko wtedy, gdy wszystkie te pola są używane w zapytaniu. Z drugiej strony, posiadanie wielu indeksów dla jednej tabeli, z jednym polem na indeks, może nie być zbyt pomocne (lub jakiekolwiek) dla zapytań, które filtrowanie/sortowanie według wielu pól.


Wspomniałeś indeksy pełnotekstowe i PKs (klucze podstawowe). Są one inne niż zwykłe indeksy, choć często służą podobnym celom.

Po pierwsze, zauważ, że klucz podstawowy jest zwykle indeksem( w MSSQL 'Clustered Index', w rzeczywistości), ale nie musi tak być w szczególności. Dla przykładu, MSSQL PK jest domyślnie indeksem klastrowym; indeksy klastrowe są wyjątkowe, ponieważ nie są oddzielnym bitem przechowywanych danych gdzie indziej, ale same dane są ułożone w tabeli w kolejności według klastrowego indeksu. Dlatego popularny PK jest wartością int, która jest automatycznie generowana z sekwencyjnymi, rosnącymi wartościami. Tak więc klastrowy indeks sortuje dane w tabeli według wartości pola. Porównaj to z tradycyjnym słownikiem; same wpisy są uporządkowane według "klucza", który jest określanym słowem.

Ale w MSSQL (sprawdź dokumentację DBMS), możesz zmienić Clustered Index to inne pole, jeśli chcesz. Czasami odbywa się to na polach opartych na datetime.


Indeksy pełnotekstowe to zupełnie różne rodzaje bestii. Używają niektórych z tych samych zasad, ale to, co robią, nie jest dokładnie takie samo, jak normalne indeksy, które opisuję. Ponadto: w niektórych DBMS ' ach, zapytania LIKE robią , a nie używają indeksu pełnotekstowego; wymagane są specjalne operatory zapytań.

Te indeksy są inne, ponieważ ich intencją nie jest znajdź / posortuj na całej wartości kolumny (liczbę, datę, krótki bit danych znaków), ale zamiast tego znajdź poszczególne słowa/frazy w indeksowanych polach tekstowych.

Mogą również często umożliwiać wyszukiwanie podobnych słów, różnych czasów, częstych błędów ortograficznych i tym podobnych, i zazwyczaj ignorują słowa szumu. Odmienny sposób ich działania sprawia, że mogą oni również potrzebować różnych operatorów, aby z nich korzystać. (ponownie sprawdź lokalną dokumentację DBMS!)

 21
Author: Andrew Barber,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-11-04 15:17:16

Ta odpowiedź jest specyficzna dla Oracle, ale główne punkty w odpowiedziach dotyczą większości relacyjnych systemów baz danych

Jak wybrać i zoptymalizować indeksy oracle?

 1
Author: CheeseConQueso,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:02:39