Wie viele Datenbankindizes sind zu viele?

Ich arbeite an einem Projekt mit einer ziemlich großen Oracle-Datenbank (obwohl meine Frage auch für andere Datenbanken gilt). Wir haben eine Weboberfläche, mit der Benutzer nach nahezu jeder möglichen Kombination von Feldern suchen können.

Um diese Suche zu beschleunigen, fügen wir den Feldern und Feldkombinationen, nach denen Benutzer unserer Meinung nach häufig suchen, Indizes hinzu. Da wir jedoch nicht genau wissen, wie unsere Kunden diese Software verwenden werden, ist es schwierig zu sagen, welche Indizes erstellt werden sollen.

Raum ist kein Problem; Wir haben ein 4-Terabyte-RAID-Laufwerk, von dem wir nur einen kleinen Bruchteil verwenden. Ich bin jedoch besorgt über die möglichen Leistungseinbußen bei zu vielen Indizes. Da diese Indizes jedes Mal aktualisiert werden müssen, wenn eine Zeile hinzugefügt, gelöscht oder geändert wird, halte ich es für eine schlechte Idee, Dutzende von Indizes in einer einzelnen Tabelle zu haben.

Wie viele Indizes werden als zu viele angesehen? 10? 25? 50? Oder sollte ich nur die wirklich, wirklich häufigen und offensichtlichen Fälle behandeln und alles andere ignorieren?

Dies hängt von den Operationen ab, die in der Tabelle ausgeführt werden.

Wenn es viele SELECTs und sehr wenige Änderungen gibt, indizieren Sie alles, was Sie möchten. Dies beschleunigt (möglicherweise) die SELECT-Anweisungen.

Wenn die Tabelle stark von UPDATEs, INSERTs + DELETEs ... betroffen ist, sind diese mit vielen Indizes sehr langsam, da sie alle bei jeder dieser Operationen geändert werden müssen

Trotzdem können Sie einer Tabelle eindeutig viele sinnlose Indizes hinzufügen, die nichts bewirken. Das Hinzufügen von B-Tree-Indizes zu einer Spalte mit zwei unterschiedlichen Werten ist sinnlos, da nichts zum Nachschlagen der Daten hinzugefügt wird. Je eindeutiger die Werte in einer Spalte sind, desto mehr profitiert ein Index.

Normalerweise gehe ich so vor.

1. Erstellen Sie ein Protokoll der tatsächlichen Abfragen, die an einem typischen Tag für die Daten ausgeführt werden.
2. Fügen Sie Indizes hinzu, damit die wichtigsten Abfragen die Indizes in ihrem Ausführungsplan treffen.
3. Vermeiden Sie die Indizierung von Feldern mit vielen Aktualisierungen oder Einfügungen
4. Holen Sie sich nach einigen Indizes ein neues Protokoll und wiederholen Sie den Vorgang.

Wie bei jeder Optimierung höre ich auf, wenn die angeforderte Leistung erreicht ist (dies impliziert offensichtlich, dass Punkt 0 bestimmte Leistungsanforderungen erhalten würde).

Alle anderen haben Ihnen gute Ratschläge gegeben. Ich habe einen zusätzlichen Vorschlag für Sie, wenn Sie vorwärts gehen. Irgendwann müssen Sie eine Entscheidung über Ihre beste Indexierungsstrategie treffen. Am Ende kann die beste geplante Indexierungsstrategie jedoch dazu führen, dass Indizes erstellt werden, die nicht verwendet werden. Eine Strategie, mit der Sie nicht verwendete Indizes finden können, ist die Überwachung der Indexnutzung. Sie tun dies wie folgt: -

alter index my_index_name monitoring usage;

Sie können dann überwachen, ob der Index von diesem Punkt an verwendet wird oder nicht, indem Sie v $ object_usage abfragen. Informationen hierzu finden Sie im Oracle® Database Administrator's Guide .

Denken Sie daran, dass Sie den Index für die erneute Überwachung einrichten müssen, wenn Sie eine Warehousing-Strategie haben, bei der Indizes vor dem Aktualisieren einer Tabelle gelöscht und anschließend neu erstellt werden. Dadurch geht der Überwachungsverlauf für diesen Index verloren.

Im Data Warehousing ist es sehr häufig, dass eine hohe Anzahl von Indizes vorhanden ist. Ich habe mit Faktentabellen mit zweihundert Spalten gearbeitet und 190 davon indiziert.

Obwohl dies mit einem Overhead verbunden ist, muss im Zusammenhang damit verstanden werden, dass wir in einem Data Warehouse eine Zeile im Allgemeinen nur einmal einfügen, sie jedoch nie aktualisieren. Sie kann dann jedoch an Tausenden von SELECT-Abfragen teilnehmen, die von der Indizierung einer beliebigen Zeile profitieren könnten die Spalten.

Für maximale Flexibilität verwendet ein Data Warehouse im Allgemeinen einspaltige Bitmap-Indizes, außer in Spalten mit hoher Kardinalität, in denen (komprimierte) btree-Indizes verwendet werden können.

Der Aufwand für die Indexpflege ist hauptsächlich mit den Kosten für das Schreiben in sehr viele Blöcke und die Blockaufteilung verbunden, wenn neue Zeilen mit Werten hinzugefügt werden, die "in der Mitte" der vorhandenen Wertebereiche für diese Spalte liegen. Dies kann durch Partitionierung und Ausrichtung der neuen Datenlasten auf das Partitionierungsschema sowie durch Verwendung direkter Pfadeinfügungen verringert werden.

Um Ihre Frage direkter zu beantworten, denke ich, dass es wahrscheinlich in Ordnung ist, zunächst das Offensichtliche zu indizieren, aber haben Sie keine Angst davor, weitere Indizes hinzuzufügen, wenn die Abfragen für die Tabelle davon profitieren würden.

Fügen Sie in einer Umschreibung von Einstein über Einfachheit so viele Indizes hinzu, wie Sie benötigen, und nicht mehr.

Im Ernst, jeder Index, den Sie hinzufügen, muss gewartet werden, wenn Daten zur Tabelle hinzugefügt werden. Bei Tabellen, die hauptsächlich schreibgeschützt sind, sind viele Indizes eine gute Sache. Bei hochdynamischen Tabellen ist weniger besser.

Mein Rat ist, die häufigsten und offensichtlichen Fälle abzudecken und dann, wenn Sie auf Probleme stoßen, bei denen Sie mehr Geschwindigkeit beim Abrufen von Daten aus bestimmten Tabellen benötigen, zu diesem Zeitpunkt Indizes auszuwerten und hinzuzufügen.

Es ist auch eine gute Idee, Ihre Indexierungsschemata alle paar Monate neu zu bewerten, um festzustellen, ob es etwas Neues gibt, das indiziert werden muss, oder von Ihnen erstellte Indizes, die für nichts verwendet werden und entfernt werden sollten .

Zusätzlich zu den Punkten, die alle anderen angesprochen haben, entstehen dem kostenbasierten Optimierer Kosten beim Erstellen eines Plans für eine SQL-Anweisung, wenn mehr Indizes vorhanden sind, da mehr Kombinationen zu berücksichtigen sind. Sie können dies reduzieren, indem Sie Bindungsvariablen korrekt verwenden, sodass SQL-Anweisungen im SQL-Cache verbleiben. Oracle kann dann eine weiche Analyse durchführen und den zuletzt gefundenen Plan wiederverwenden.

Wie immer ist nichts einfach. Wenn es sich um verzerrte Spalten und Histogramme handelt, kann dies eine schlechte Idee sein.

In unseren Webanwendungen beschränken wir die zulässigen Suchkombinationen. Andernfalls müssten Sie buchstäblich jede Kombination auf Leistung testen, um sicherzustellen, dass Sie kein lauerndes Problem haben, das eines Tages jemand finden wird. Wir haben auch Ressourcenbeschränkungen implementiert, um dies zu verhindern und Probleme an anderer Stelle in der Anwendung zu verursachen, falls etwas schief gehen sollte.

Ich habe einige einfache Tests an meinem realen Projekt und meiner realen MySQL-Datenbank durchgeführt. Ich habe bereits in diesem Thema geantwortet: Was kostet die Indizierung mehrerer Datenbankspalten?

Aber ich denke, es wird besser sein, wenn ich es hier zitiere:

Ich habe einige einfache Tests mit meinem realen Projekt und meiner realen MySQL-Datenbank durchgeführt.

Meine Ergebnisse sind: Hinzufügen eines durchschnittlichen Index (1-3 Spalten in einem Index) zu einer Tabelle - macht Einfügungen um 2,1% langsamer. Wenn Sie also 20 Indizes hinzufügen, sind Ihre Einfügungen um 40-50% langsamer. Ihre Auswahl ist jedoch 10-100-mal schneller.

Ist es also in Ordnung, viele Indizes hinzuzufügen? - Es kommt darauf an :) Ich habe dir meine Ergebnisse gegeben - Du entscheidest!

Wie viele Indizes Sie letztendlich benötigen, hängt vom Verhalten Ihrer Anwendungen ab, die auf Ihrem Datenbankserver ausgeführt werden.

Im Allgemeinen werden Ihre Indizes umso schmerzhafter, je mehr Sie einfügen. Bei jeder Einfügung müssen alle Indizes, die diese Tabelle enthalten, aktualisiert werden.

Wenn Ihre Anwendung eine anständige Lesemenge aufweist, oder noch mehr, wenn fast ausschließlich gelesen wird, sind Indizes der richtige Weg, da sich die Leistung bei sehr geringen Kosten erheblich verbessern wird.

Meiner Meinung nach gibt es keine statische Antwort. Diese Art von Dingen fällt unter "Leistungsoptimierung".

Es kann sein, dass alles, was Ihre App tut, von einem Primärschlüssel nachgeschlagen wird, oder es könnte das Gegenteil sein, dass Abfragen über uneingeschränkte Feldkombinationen durchgeführt werden und jedes einzelne zu einem bestimmten Zeitpunkt verwendet werden kann.

Über die reine Indizierung hinaus wird Ihre Datenbank neu programmiert, um berechnete Suchfelder, Aufteilungstabellen usw. einzuschließen. Dies hängt wirklich von Ihren Ladeformen und Abfrageparametern ab, wie viel / welche Daten von einer Abfrage "wirklich" abgerufen werden müssen.

Wenn Ihre gesamte Datenbank mit Fassaden mit gespeicherten Prozeduren konfrontiert ist, wird das Drehen etwas einfacher, da Sie sich nicht um jede Ad-hoc-Abfrage kümmern müssen. Oder Sie haben ein tiefes Verständnis für die Art von Abfragen, die Ihre Datenbank treffen, und können die Optimierung auf diese beschränken.

Für SQL Server fand ich den Database Engine Tuning Advisor nützlich - Sie richten 'typische' Workloads ein und er kann Empfehlungen zum Hinzufügen / Entfernen von Indizes und Statistiken geben. Ich bin sicher, dass andere DBs ähnliche Tools haben, entweder "offiziell" oder von Drittanbietern.

Dies ist wirklich eher eine theoretische als eine praktische Frage. Die Auswirkungen von Indizes auf Ihre Leistung hängen von Ihrer Hardware, der Oracle-Version, den Indextypen usw. ab. Gestern habe ich gehört, dass Oracle einen dedizierten Speicher von HP angekündigt hat, der mit 11g-Datenbanken zehnmal schneller arbeiten soll. Für Ihren Fall gibt es mehrere Lösungen: 1. Haben Sie eine große Anzahl von Indizes (> 20) und erstellen Sie diese täglich (jede Nacht) neu. Dies ist besonders nützlich, wenn die Tabelle täglich Tausende von Aktualisierungen / Löschungen erhält. 2. Partitionieren Sie Ihre Tabelle (falls dies für Ihr Datenmodell gilt). 3. Verwenden Sie eine separate Tabelle für neue / aktualisierte Daten und führen Sie einen nächtlichen Prozess aus, bei dem die Daten miteinander kombiniert werden. Dies würde eine Änderung Ihrer Anwendungslogik erfordern. 4. Wechseln Sie zu IOT (Index Organized Table), wenn Ihre Daten dies unterstützen.

Natürlich könnte es für einen solchen Fall viel mehr Lösungen geben. Mein erster Vorschlag an Sie wäre, die Datenbank in eine Entwicklungsumgebung zu klonen und einige Stresstests dagegen durchzuführen.

Wenn Sie hauptsächlich lesen (und nur wenige Updates), gibt es wirklich keinen Grund, nicht alles zu indizieren, was Sie zum Indizieren benötigen. Wenn Sie häufig aktualisieren, müssen Sie möglicherweise vorsichtig sein, wie viele Indizes Sie haben. Es gibt keine feste Zahl, aber Sie werden feststellen, wenn sich die Dinge verlangsamen. Stellen Sie sicher, dass Ihr Clustered-Index auf der Grundlage der Daten am sinnvollsten ist.

Eine Sache, die Sie in Betracht ziehen können, ist das Erstellen von Indizes für eine Standardkombination von Suchvorgängen. Wenn Spalte1 häufig durchsucht wird und Spalte2 häufig damit verwendet wird und Spalte3 manchmal mit Spalte2 und Spalte1 verwendet wird, kann ein Index für Spalte1, Spalte2 und Spalte3 in dieser Reihenfolge für jeden dieser drei Umstände verwendet werden Nur ein Index muss gepflegt werden.

Ein Index verursacht Kosten, wenn die zugrunde liegende Tabelle aktualisiert wird. Ein Index bietet einen Vorteil, wenn er zum Schließen einer Abfrage verwendet wird. Für jeden Index müssen Sie die Kosten gegen den Nutzen abwägen. Wie viel langsamer läuft die Abfrage ohne den Index? Wie viel Nutzen läuft schneller? Können Sie oder Ihre Benutzer die langsame Geschwindigkeit tolerieren, wenn der Index fehlt?

Können Sie die zusätzliche Zeit tolerieren, die zum Abschließen eines Updates erforderlich ist?

Sie müssen Kosten und Nutzen vergleichen. Das ist speziell für Ihre Situation. Es gibt keine magische Anzahl von Indizes, die die Schwelle von "zu vielen" überschreiten.

Es gibt auch die Kosten für den Speicherplatz, der zum Speichern des Index benötigt wird, aber Sie haben gesagt, dass dies in Ihrer Situation kein Problem darstellt. Dasselbe gilt in den meisten Situationen, wenn man bedenkt, wie billig Speicherplatz geworden ist.

Wie viele Spalten gibt es? Mir wurde immer gesagt, ich solle einspaltige Indizes erstellen, keine mehrspaltigen Indizes. Also nicht mehr Indizes als die Anzahl der Spalten, IMHO.

Es kommt wirklich darauf an, keinen Index hinzuzufügen, es sei denn, Sie wissen (und dies bedeutet häufig das Sammeln von Nutzungsstatistiken), dass er weitaus häufiger verwendet wird als aktualisiert.

Jeder Index, der diese Kriterien nicht erfüllt, kostet Sie mehr für die Neuerstellung als die Leistungseinbuße, wenn Sie ihn in dem seltsamen Fall, in dem er verwendet wurde, nicht haben.

Der SQL Server bietet Ihnen einige gute Tools, mit denen Sie sehen können, welche Indizes tatsächlich verwendet werden. Dieser Artikel, http://www.mssqltips.com/tip.asp?tip=1239 , enthält einige Abfragen, mit denen Sie einen besseren Einblick in die Verwendung eines Index im Gegensatz zur Aktualisierung erhalten.

Es basiert vollständig auf den Spalten, die in der Where-Klausel verwendet werden. Und als Daumen der Regel müssen wir Indizes für Fremdschlüsselspalten haben, um DEADLOCKS zu vermeiden. Der AWR-Bericht sollte regelmäßig analysiert werden, um die Notwendigkeit von Indizes zu verstehen.