Ich möchte hier hinzufügen, dass unterschiedliche Datenbanken unterschiedliche Strategien erfordern. Vergleichen wir zum Beispiel MySQL mit InnoDB und PostgreSQL.
InnoDB
InnoDB-Tabellen sind im Grunde genommen ein B-Tree-Index des Primärschlüssels, der um die Zeileninformationen im Indexeintrag erweitert wird. Überprüfungen der physischen Reihenfolge werden nicht unterstützt und alle Überprüfungen erfolgen in logischer Reihenfolge. Das bedeutet zwei Dinge:
Ein sequentieller Scan in Innodb generiert eine Menge zufälliger Festplatten-E / A und
Der Primärschlüsselindex muss durchlaufen werden, unabhängig davon, ob ein Sekundärindex verwendet wird.
Primärschlüssel-Lookups sind in diesem Modell schneller als in jedem anderen Ansatz.
In diesem Fall ist es sehr wichtig, genügend Felder in mehrseitigen Tabellen zu indizieren. Die typische Regel ist, alles zu indexieren, nach dem Sie filtern möchten.
PostgreSQL
PostgreSQL verwendet Heap-Dateien, eine Tabelle pro Datei (einige Tabellen können viele Dateien sein), wobei Tupel aus dem freien Speicherplatz dieses Heaps zugewiesen werden. Physische Order-Scans werden unterstützt. Damit ein Scan nach logischer Reihenfolge funktioniert, muss ein Index hinzugefügt werden.
Primärschlüssel in PostgreSQL sind im Grunde eine Teilmenge eindeutiger Indizes, bei denen keine Werte NULL sein dürfen. UNIQUE-Einschränkungen werden unter Verwendung impliziter Indizes durchgeführt, und verschiedene andere Indextypen werden mit unterschiedlichen Operationen unterstützt, die im Index möglich sind.
Das heisst:
Primärschlüssel-Lookups unter der Annahme, dass eine relativ große Tabelle eine Indexdatei und eine Tabellendatei trifft . Dies ist erheblich langsamer als der Ansatz von MySQL, bei dem nur der Index durchlaufen werden muss und die Zeile im Index enthalten ist.
Bei physischen Ordnungsprüfungen ist die Leistung wesentlich besser, da weniger zufällige Datenträger-E / A-Vorgänge ausgeführt werden müssen, wenn eine erhebliche Anzahl von Zeilen verarbeitet werden soll.
Sekundärindex-Scans sind leistungsfähiger als MySQL, da nur ein Index durchlaufen werden muss, um zum physischen Teil der Tabelle zu gelangen.
In diesem Modell sind häufig Indizes erforderlich, aber der Planer hat mehr Freiheit, einen Index zu verwenden, und die Auswirkungen der Nichtverwendung sind häufig weniger schwerwiegend. Die Tabellen sind allgemeiner optimiert (anstatt sich auf pkey-Lookups zu spezialisieren), sodass weniger Indizes erforderlich sind.
TL; DR
Kennen Sie Ihre RDBMS.