Konieczność indeksowania kluczy obcych

Walczę z indeksami, kluczami głównymi i kluczami obcymi ... I potrzebą posiadania ich wszystkich.

Jeśli mam dwie tabele, obie mają liczbę całkowitą jako klucz podstawowy.
Pierwsza tabela odwołuje się poprzez FK do klucza podstawowego drugiej tabeli.

W obu tabelach mam indeks klucza podstawowego w kolumnie ID
Utworzyłem ograniczenie FK dotyczące table1.ref_fieldodwoływania się do PK drugiej tabeli ( table2.id)
i dodałem indeks do table1.ref_field

Czy to najlepszy sposób na uporządkowanie tych indeksów, kluczy głównych i kluczy obcych?

— StUrb
źródło

Twój projekt jest dobry. Jeśli masz problem z wydajnością (którego nie znasz w czasie projektowania), powinieneś utworzyć indeks w kolumnie table1.ref_field, w tej samej kolejności (ASC), co kolumna table2.id. Poprawi to wydajność połączeń między tabelami / kolumnami. Utrzymanie dowolnego indeksu wiąże się z dodatkowymi kosztami, dlatego warto porównać ten koszt z korzyścią płynącą z lepszej wydajności.

PostgreSQL nie tworzy automatycznie takich indeksów na kolumnach kluczy obcych, które odwołują się do innych kolumn, niestety, więc musisz to zrobić sam.

Oto pytanie StackOverflow na ten sam temat:

Postgresy i indeksy dotyczące kluczy obcych i kluczy podstawowych

Oto zapytanie, które pomoże ustalić, gdzie możesz skorzystać z dodania takiego indeksu:

Postgresql: Indeksy dotyczące kluczy obcych

— peterk411
źródło

Nie zawsze jest to niefortunne - jeśli nie znajdujesz się DELETEw tabeli, do której się odwołujesz, może zaoszczędzić dużo I / O i procesora, unikając utrzymywania nieużywanego indeksu. Myślę, że powinien on zostać utworzony domyślnie, po prostu mam opcję powstrzymania jego tworzenia.

— Craig Ringer

Craig Ringer Nie tylko DELETE może mieć na to wpływ, ale jeśli wybierzesz partent do tabel potomnych, będziesz mieć również problemy z wydajnością. Ta dokumentacja Oracle wyjaśnia więcej: asktom.oracle.com/pls/asktom/…

— 777Anon