it-swarm.com.de

Ist es schlecht, wenn der Indexbereich größer als der Datenbereich ist?

Oft muss ich Abfragen für große Tabellen ausführen, die nicht den richtigen Index haben. Deshalb bitte ich den DBA, einen solchen Index zu erstellen. Als erstes schaut er sich die Tabellenstatistik an und sieht die Größe des Indexbereichs.

Oft sagte er mir, ich solle eine alternative Lösung finden, weil "der Index bereits größer als die Tabelle ist". Er ist der Meinung, dass der Index kleiner sein muss als die Daten, weil er mir sagte: "Haben Sie den Index jemals in einem Buch gesehen? Er ist viel kleiner als das Buch selbst, und so sollte ein Tabellenindex sein.".

Ich glaube nicht, dass seine Philosophie richtig ist, aber ich kann ihn nicht herausfordern, weil er ein leitender DBA ist und ich ein Entwickler bin. Ich denke, wenn eine Abfrage einen Index benötigt, sollte der Index nur erstellt werden, anstatt "Problemumgehungen" zu finden, die nur unlesbare und nicht wartbare SPs machen.

Ich wähle nur die erforderlichen Spalten aus. Das Problem ist, dass ich nach Datum filtere, sodass die Engine notwendigerweise einen Tabellenscan durchführt, um die Spalten abzugleichen. Die Abfrage wird einmal am Tag und nachts ausgeführt, um Statistiken zu sammeln. Die Ausführung dauert jedoch 15 Minuten (wir haben eine weitere feste Regel: Kein Vorgang sollte länger als 3 Minuten dauern).

Der DBA zeigte mir die Indexstatistik. Es gab ungefähr 10 Indizes in dieser Tabelle, von denen nur 6 verwendet wurden (Statistiken zeigten null Treffer für 4 von ihnen). Dies ist ein großes System, an dem über 20 Entwickler teilnehmen. Die Indizes wurden aus irgendeinem Grund erstellt und wahrscheinlich nicht mehr verwendet.

Wir müssen SQL Server 2008 unterstützen, da die Test-DBs auf diesen ausgeführt werden. Aber die Kunden sind alle auf 2014 und 2016.

27
hjf

Stellen Sie sich das Indexdesign wie einen Schiebeschalter vor. Sie können diesen roten Dreiecksschalterknopf an einer beliebigen Stelle entlang der gewünschten Linie bewegen:

(Index design decisions

Normalerweise messe ich es nicht in Bezug auf die Größe - ich denke normalerweise in Bezug auf die Indexmenge, aber die Größe wäre auch in Ordnung.

Es hört sich so an, als ob Ihr DBA denkt, der Schalter sei zu weit rechts - Sie haben zu viele Indizes hinzugefügt und Löschungen/Aktualisierungen/Einfügungen werden zu langsam ausgeführt.

Anstatt darüber zu streiten, wo sich der Switch befindet, fragen Sie ihn nach den Leistungsproblemen, die Sie aufgrund der hohen Anzahl von Indizes haben. Möglicherweise beschweren sich Ihre Benutzer über die Geschwindigkeit beim Löschen/Aktualisieren/Einfügen, oder er sieht Wartezeiten für Sperren, oder es fällt ihm aufgrund seiner Größe schwer, die Datenbank zu sichern.

Mein Ausgangspunkt ist normalerweise 5 und 5: ungefähr 5 Indizes pro Tabelle mit ungefähr 5 oder weniger Feldern pro Index. An dieser Zahl ist nichts Magisches - sie kommt nur von der Tatsache, dass ich 5 Finger an jeder Hand habe, so dass es einfach ist, meine Hände hochzuhalten und die Regel zu erklären.

Möglicherweise müssen Sie viele WENIGER Indizes als 5 haben, wenn Ihre Arbeitslast stark auf Lösch-/Aktualisierungs-/Einfügevorgänge ausgerichtet ist und Sie nicht über genügend Hardware-Leistung verfügen, um Schritt zu halten.

Möglicherweise können Sie viele MEHR Indizes haben, wenn Ihre Arbeitslast größtenteils schreibgeschützt ist oder wenn Sie stark in Hardware investieren (z. B. die gesamte Datenbank im Speicher zwischenspeichern und den gesamten Solid-State-Speicher darunter haben).

45
Brent Ozar

Ich mag Brents Antwort und ich habe sie positiv bewertet. Ich möchte jedoch eine andere Perspektive hinzufügen. Ich habe als Benutzer, Entwickler und DBA gearbeitet und bin der Meinung, dass Meinungen nicht relevant sind. Ich glaube, es liegt am Benutzer (oder Stakeholder), zu entscheiden, wie eine Abfrage ausgeführt wird und wie lange es dauert, bis Ergebnisse erzielt werden. Es ist dann Sache des Entwicklers und des DBA, zusammenzuarbeiten, um dies zu erreichen.

Wenn die DBA-Position in Ihrem Unternehmen für dieses Thema zuständig ist, kann sie Ihre Anfrage analysieren und Vorschläge für ein besseres Abfragedesign machen oder auf die Leistung antworten.

Wenn die Abfrage- und/oder Datenstruktur nicht geändert werden kann, um das Ziel zu erreichen, sind es meiner Meinung nach drei Möglichkeiten.

  1. Langsamer Datenabruf
  2. Langsame Datenaktualisierung
  3. Weitere Hardwareressourcen $$$$

Natürlich hat jede Situation viele Variablen, die von mehreren Geschäfts- und Technologiefaktoren abhängen, aber ich glaube, dass die drei Optionen für die meisten, wenn nicht alle Fälle gelten.

5
Joe

Auch der Wunsch, mehr als "The Ozar 5" -Indizes in einer Tabelle zu haben , zeigt wahrscheinlich an, dass Sie viele verschiedene Arten von leselastigen Abfragen auf der haben Tabelle.

Welches wahrscheinlich anzeigt , dass Sie von einem Clustered oder Non-Clustered Columnstore Index in der Tabelle profitieren könnten.

Anstatt den optimalen Index für jeden der N verschiedenen Zugriffspfade zu haben, bietet Ihnen ein Spaltenspeicher ein superschnelles Scannen und die Möglichkeit, nicht benötigte Spalten und Zeilensegmente zu überspringen. Sie können also eine kleine Anzahl von BTree-Indizes für überkritische Transaktionen verwenden und für alles andere auf den Spaltenspeicher zurückgreifen.

Columnstore-Indizes funktionieren in OLTP-lastigen Workloads mit SQL Server 2016+. Weitere Informationen finden Sie in der Dokumentation zu Operational Analytics in Echtzeit .

Scheint zu streng, um Indizes> Tabelle zu verbieten. Wenn sich Ihre Tabelle selten ändert (oder nachts ändert, wenn nicht viel Konkurrenz um Ressourcen besteht) und sie auf viele verschiedene Arten häufig abgefragt wird, können viele große Indizes gerechtfertigt werden. DBAs sollten auch darauf achten, ihre Nasen nicht dort zu stecken, wo sie nicht hingehören. Wenn er Ihnen/Ihrem System eine Begrenzung auf Gigabyte gibt, sollte es ihm egal sein, wie dieser Speicherplatz genutzt wird. Wenn er überarbeitet ist, könnte dies der Grund sein.

Es gibt jedoch viele Dinge zu beachten:

  • Viele Indizes verlangsamen das Einfügen/Aktualisieren/Löschen. Wenn sich Ihr Tisch also stark ändert, achten Sie darauf, nicht zu viele davon zu erstellen.
  • Platz kann auch ein Problem sein. Nicht nur, weil Gigabyte Geld kosten (heutzutage nicht viel), sondern auch, weil die Sicherung langsamer ist (abhängig davon, wie die Sicherung durchgeführt wird).
  • Die meisten seriösen Datenbanken können überwacht werden, um Indizes zu finden, die selten oder nie verwendet werden. Ziehen Sie in Betracht, einige von ihnen fallen zu lassen.
  • Manchmal denken Sie, Sie brauchen einen Index, aber wenn Sie Ihre Abfrage genauer untersuchen, kann sie mit demselben Ergebnis und ohne den Index anders eingestellt und neu geschrieben werden. Verwenden Sie EXPLAIN Plan, um festzustellen, ob der Index verwendet wird oder nicht.
  • Manchmal können die letzten Spalten aus einem mehrspaltigen Index entfernt werden, ohne dass die Leistung beeinträchtigt wird. Und manchmal kann dies sogar Abfragen beschleunigen, da der Indexspeicherplatz kleiner ist und zu einem bestimmten Zeitpunkt mehr Index im Speicher gespeichert/zwischengespeichert wird.
  • Funktionsbasierte Indizes können normale ersetzen, um mehr Platz zu sparen. Beispiel: Anstatt nach dem vollständigen Nachnamen zu fragen, fragen Sie auch nach den ersten beiden Buchstaben (where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput>) und create index i on customers(substr(surname,1,2)). Dies kann schnell genug sein und Ihr Index wird kleiner.
  • Datenbanken unterstützen verschiedene Arten von Indizes. Einige Typen benötigen weniger Speicherplatz als andere. Vielleicht können einige Ihrer Indizes in einen weniger platzraubenden Typ konvertiert werden? Stellen Sie sicher, dass Sie zuerst die verschiedenen Indextypen verstehen und wissen, für welche Situationen sie gut und welche schlecht sind.
  • Wenn nur ein seltener Stapeljob einen bestimmten Index benötigt, sollten Sie diesen Index nur für diesen Stapeljob erstellen und anschließend löschen.
1
Kjetil S.