Sollen die Fremdschlüssel der Nachschlagetabelle immer indiziert werden?

Question

Wenn ich eine Nachschlagetabelle mit sehr wenigen Datensätzen (z. B. weniger als zehn) habe, sollte ich mich bemühen, einen Index auf den Fremdschlüssel einer anderen Tabelle zu legen, an die er angehängt ist? Benötigt die Lookup-Tabelle einen Index für den Primärschlüssel?

Gibt es speziell einen Leistungsvorteil, der den Verwaltungsaufwand für die Indizes überwiegt? Wenn nicht, gibt es andere Vorteile als die Geschwindigkeit?

Hinweis: ein Beispiel für eine Lookup-Tabelle könnte Order Status, wo die Tupel sind:

1 - Order Received 
2 - In Process 
3 - Shipped 
4 - Paid 

Answer 1

Auf einem Transaktionssystem kann es keinen wesentlichen Vorteil geben, einen Index auf eine solche Spalte zu setzen (d. H. Eine Spalte mit niedriger Kardinalitätsreferenz), da der Abfrageoptimierer sie wahrscheinlich nicht verwenden wird. Außerdem wird bei Schreibvorgängen in der Tabelle zusätzlicher Plattenverkehr generiert, da die Indizes aktualisiert werden müssen. Daher ist es für Kardinalitäten mit niedriger Kardinalität in einer Transaktionsdatenbank normalerweise besser, die Spalten nicht zu indizieren. Dies gilt insbesondere für hochvolumige Systeme.

Beachten Sie, dass Sie immer noch die FK für referenzielle Integrität wünschen und dass die FK-Suche in einer kleinen Referenztabelle wahrscheinlich keine E/A generiert, da die Lookup-Tabelle fast immer zwischengespeichert wird.

Sie können jedoch feststellen, dass Sie die Spalte aus irgendeinem Grund in einen zusammengesetzten Index einschließen möchten - vielleicht, um einen Deckungsindex für eine häufig verwendete Abfrage zu erstellen.

Auf einem Tisch, die häufig Massen geladen (beispielsweise ein Data-Warehouse) der Index Schreibverkehr wird viel größer sein als die der Tabellenlast ist, wenn Sie viele indizierte Spalten haben. Sie müssen wahrscheinlich die FKs und Indizes für eine Massenladung löschen oder deaktivieren, wenn Indizes vorhanden sind.

Auf einem Star Schema können Sie von der Indizierung niedriger Kardinalitätsspalten profitieren, sogar auf SQL Server. Wenn Sie eine hochselektive Abfrage durchführen (d. H. Eine, bei der der Abfrageoptimierer entscheidet, dass der zurückgegebene Zeilensatz klein ist), kann er einen "Sternabfrageplan" ausführen, bei dem eine Technik verwendet wird, die als Indexschnittpunkt bezeichnet wird.

Im Allgemeinen sollten Abfragepläne für ein Sternschema auf einem Tabellenscan der Fakttabelle oder einem hochselektiven Prozess basieren, der die Fakttabelle bucht und dann einen kleineren Satz von Zeilen zurückgibt. Die Indexüberschneidung ist für den letzteren Abfragetyp effizient, da die Auswahl vor dem Ausführen einer E/A in der Fakttabelle aufgelöst werden kann.

Bitmap-Indizes sind ein echter Gewinn für Spalten mit niedriger Kardinalität auf Plattformen wie Oracle, die sie unterstützen, aber SQL Server nicht. Dennoch können Kardinalitätsindizes weiterhin in Star-Abfrageplänen auf SQL Server verwendet werden.

Answer 2

Meine persönliche Meinung ist, dass Sie ... es jetzt klein, aber immer antizipieren Ihre Tabellen wächst in Größe. Ein gutes Datenbankschema wird leicht mit mehr Datensätzen wachsen. Fremdschlüssel sind fast immer eine gute Idee.

Answer 3

Ja, immer einen Index haben.

Der Abfrageoptimierer eines modernen Datenbankverwaltungssystems (DBMS) wird feststellen, welches schneller ist: (1) tatsächlich aus einem Index einer Spalte lesen, (2) einen vollständigen Tabellenscan ausführen.

Die Tabellengröße (Anzahl der Zeilen) muss "groß genug" sein, damit der Index berücksichtigt werden kann.

Answer 4

In SQL-Server ist der Primärschlüssel der Clustered-Index, wenn es noch keinen gibt (Clustered-Index, der ist).

Answer 5

Ja zu beiden. Immer als Faustregel indexieren.

Punkte:

• Sie können auch keine FK ohne einen eindeutigen Index für die Nachschlagtabelle
• Was ist, wenn Sie wollen in der Lookup-Tabelle zu löschen oder zu aktualisieren einrichten? Vor allem zufällig ...

Allerdings sagen wir das nicht immer.

Wir haben sehr OLTP-Tabelle (5 Millionen Zeilen + pro Tag) mit mehreren übergeordneten Tabellen. Wir indizieren nur die FK-Spalten, wo wir sie brauchen. Wir gehen davon aus, dass bei einigen Elterntabellen keine Löschungen/Schlüsselaktualisierungen vorgenommen werden, so dass wir weniger Arbeitsaufwand und Speicherplatz benötigen.

Wir haben die SQL Server 2005 DMVs verwendet, um festzustellen, dass Indizes nicht verwendet wurden. Wir haben immer noch die FK an Ort und Stelle.