Czy muszę tworzyć indeksy na kluczach obcych?

Mam tabelę A i tabelę B. A posiada klucz obcy do B na głównym kluczu B, B_ID.

Z jakiegoś powodu (wiem, że są uzasadnione powody) nie używa indeksu, gdy dołączam te dwie tabele do klucza.

Czy muszę oddzielnie tworzyć indeks na A.B_ID czy powinno to świadczyć o istnieniu klucza obcego?

Author: aw crud, 2010-11-08

6 answers

Samo ograniczenie klucza obcego nie dostarcza indeksu - trzeba (i powinno) zostać utworzone.

 115
Author: DCookie,
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-08 19:25:41

Utworzenie klucza obcego nie powoduje automatycznego utworzenia indeksu Na A. B_ID. Z punktu widzenia wydajności zapytań, utworzenie osobnego indeksu Na A. B_ID miałoby więc sens.

Jeśli kiedykolwiek usuniesz wiersze w B, zdecydowanie chcesz, aby A. B_ID był indeksowany. W przeciwnym razie Oracle będzie musiał wykonać pełne skanowanie tabeli na A za każdym razem, gdy usuniesz wiersz z B, aby upewnić się, że nie ma osieroconych rekordów (w zależności od wersji Oracle mogą wystąpić dodatkowe implikacje blokowania no, ale te są zmniejszone w nowszych wersjach Oracle).

 38
Author: Justin Cave,
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-08 19:24:55

Tylko po to, aby uzyskać więcej informacji: Oracle nie tworzy indeksu automatycznie (tak jak w przypadku unikalnych ograniczeń), ponieważ (a) nie jest wymagane egzekwowanie ograniczenia i (B) w niektórych przypadkach nie jest ono potrzebne.

w większości przypadków jednak będziesz chciał utworzyć indeks (w rzeczywistości w Oracle Apex jest raport "niezindeksowanych kluczy obcych").

Gdy aplikacja musi być w stanie usunąć wiersz w tabeli nadrzędnej lub zaktualizować wartość PK (która jest rzadsza), DML będzie cierpieć, jeśli indeks nie istnieje, ponieważ będzie musiał zablokować całą tabelę potomną.

Przypadek, w którym zazwyczaj wybieram a nie , Aby dodać indeks, polega na tym, że FK jest do tabeli "danych statycznych", która definiuje domenę kolumny (np. tabelę kodów stanu), gdzie aktualizacje i usuwanie w tabeli nadrzędnej nigdy nie są wykonywane bezpośrednio przez aplikację. Jeśli jednak dodanie indeksu do kolumny daje korzyści ważnym zapytaniom w aplikacji, to indeks nadal będzie dobrym pomysł.

 22
Author: Jeffrey Kemp,
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-09 00:31:06

SQL Server nigdy nie umieszczał indeksów na kolumnach kluczy obcych automatycznie-sprawdź doskonały wpis Kim Tripp na blogu na tle i historii tego miejskiego mitu.

Zazwyczaj dobrym pomysłem jest indeksowanie kolumn z kluczem obcym - więc tak, zalecałbym upewnienie się, że każda kolumna FK jest wspierana przez indeks; niekoniecznie tylko na tej jednej kolumnie - może sensowne jest utworzenie indeksu na dwóch lub trzech kolumnach z kolumną FK jako pierwszą. Zależy od scenariusza i danych.

 12
Author: marc_s,
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-08 20:02:40

Ze względu na wydajność należy utworzyć indeks. Jest używany w operacjach delete w tabeli głównej (aby sprawdzić, czy usuwany rekord nie jest używany) oraz w połączeniach, w których zwykle występuje klucz obcy. Tylko kilka tabel (nie tworzę ich w logach) może być, że nie potrzebują indeksu, ale prawdopodobnie, w tym przypadku prawdopodobnie nie potrzebujesz również ograniczenia klucza obcego.

Ale

Istnieją bazy danych, które już automatycznie tworzą indeksy na kluczach obcych. Jet Silnik (Pliki Microsoft Access) Firebird MySQL

FOR SURE

SQL Server Oracle

NIE

 5
Author: bubi,
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
2014-11-05 18:24:07

Jak w przypadku czegokolwiek związanego z wydajnością, zależy to od wielu czynników i nie ma silve bullet np. w środowisku o bardzo wysokiej aktywności utrzymanie indeksu może być nie do przyjęcia.

Najistotniejsza tutaj wydaje się selektywność: jeśli wartości w indeksie byłyby wysoce zduplikowane, może dać lepszą wydajność upuszczenie indeksu (jeśli to możliwe) i pozwolić na skanowanie tabeli.

 1
Author: onedaywhen,
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-09 08:57:41