Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

SQL Server-Indizes:Wichtige Anforderungen, Auswirkungen auf die Leistung und Überlegungen

SQL Server-Indizes werden verwendet, um Daten schneller abzurufen und Engpässe zu reduzieren, die sich auf kritische Ressourcen auswirken. Indizes für eine Datenbanktabelle dienen als Technik zur Leistungsoptimierung. Sie fragen sich vielleicht – wie steigern Indizes die Abfrageleistung? Gibt es gute und schlechte Indizes? Angenommen, Sie haben eine Tabelle mit 50 Spalten. Ist es eine gute Idee, Indizes für jede der Spalten zu erstellen? Wenn wir mehrere Indizes erstellen, hilft es dabei, SQL-Abfragen schneller auszuführen?

Alles gute Fragen, aber bevor wir eintauchen, ist es wichtig zu wissen, warum Indizes überhaupt erforderlich sind.

Stellen Sie sich vor, Sie besuchen eine Stadtbibliothek mit einer Sammlung von Tausenden von Büchern. Sie suchen ein bestimmtes Buch, aber wie werden Sie es finden? Wenn Sie jedes Buch in jedem Regal durchgehen, kann es Tage dauern, bis Sie es finden. Dasselbe gilt für eine Datenbank, wenn Sie nach einem Datensatz aus den Millionen von Zeilen suchen, die in einer Tabelle gespeichert sind.

Ein SQL Server-Index ist in einem B-Tree-Format gestaltet, das aus einem Stammknoten oben und einem Blattknoten unten besteht. Für unser Beispiel mit Bibliotheksbüchern gibt ein Benutzer eine Abfrage aus, um nach einem Buch mit der ID 391 zu suchen. In diesem Fall beginnt die Abfragemaschine mit dem Durchlaufen vom Stammknoten und bewegt sich zum Blattknoten.

Wurzelknoten –> Zwischenknoten –> Blattknoten.

Die Abfragemaschine sucht auf der Zwischenebene nach der Referenzseite. In diesem Beispiel besteht der erste Zwischenknoten aus Buch-IDs von 1–500 und der zweite Zwischenknoten aus 501–1000.

Basierend auf dem Zwischenknoten durchquert die Abfragemaschine den B-Baum, um nach dem entsprechenden Zwischenknoten und dem Blattknoten zu suchen. Dieser Blattknoten kann aus tatsächlichen Daten bestehen oder basierend auf dem Indextyp auf die tatsächliche Datenseite zeigen. In der folgenden Abbildung sehen wir, wie der Index durchlaufen wird, um mithilfe von SQL Server-Indizes nach Daten zu suchen. In diesem Fall muss SQL Server nicht jede Seite durchgehen, lesen und nach einem bestimmten Buch-ID-Inhalt suchen.

Auswirkungen von Indizes auf die Leistung von SQL Server

Im vorherigen Bibliotheksbeispiel haben wir die potenziellen Auswirkungen auf die Indexleistung untersucht. Sehen wir uns die Abfrageleistung mit und ohne Index an.

Angenommen, wir benötigen Daten für die [SalesOrderID] 56958 aus der Tabelle [SalesOrderDetail_Demo].

WÄHLEN Sie *
FROM [AdventureWorks].[Sales].[SalesOrderDetail_Demo]
wobei SalesOrderID=56958

Diese Tabelle enthält keine Indizes. Eine Tabelle ohne Indizes wird in SQL Server als Heap-Tabelle bezeichnet.

Von hier aus möchten Sie die obige select-Anweisung ausführen und den tatsächlichen Ausführungsplan anzeigen. Diese Tabelle enthält 121317 Datensätze. Es führt einen Tabellenscan durch, was bedeutet, dass es alle Zeilen in einer Tabelle liest, um die spezifische [SalesOrderID].

zu finden

Wenn Sie den Mauszeiger über das Tabellen-Scan-Symbol bewegen, wird angezeigt, dass die tatsächliche Ergebnismenge 2 Zeilen enthält, aber zu diesem Zweck alle Zeilen in dieser Tabelle gelesen wurden.

  • Anzahl gelesener Zeilen:121317
  • Die tatsächliche Anzahl der Zeilen für die Ausführung:2

Stellen Sie sich nun eine Tabelle mit Millionen oder Milliarden Zeilen vor. Es empfiehlt sich nicht, alle Datensätze in der Tabelle zu durchlaufen, um einige Zeilen zu filtern. In einem Datenbanksystem mit umfangreicher Online-Transaktionsverarbeitung (OLTP) werden die Serverressourcen (CPU, E/A, Arbeitsspeicher) nicht effektiv genutzt, weshalb der Benutzer mit Leistungsproblemen konfrontiert werden könnte.

Lassen Sie uns nun die obige select-Anweisung mit der Tabelle mit Indizes ausführen. Diese Tabelle hat einen gruppierten Primärschlüsselindex und zwei nicht gruppierte Indizes für die Spalten [ProductID] und [rowguid]. Wir werden später über die verschiedenen Arten von Indizes in SQL Server sprechen.

Wenn Sie jetzt die select-Anweisung mit demselben Prädikat erneut ausführen, zeigt der Ausführungsplan das Leistungsproblem an. Der Abfrageoptimierer entscheidet sich für die Clustered-Index-Suche anstelle eines Clustered-Index-Scans.

In den Details der Clustered-Index-Suche wird angezeigt, dass der Abfrageoptimierer die in der Ausgabe angegebenen Zeilen genau gelesen hat.

Um Ihnen eine vergleichende Analyse zu bieten, vergleichen wir den Ausführungsplan mit und ohne SQL Server-Index. Weitere Informationen finden Sie in SQL Shacks Artikel Vergleichen von Abfrageausführungsplänen in SQL Server 2016.

Sehen Sie sich für dieses Beispiel die hervorgehobenen Werte in der Clustered-Index-Suche und dem Tabellen-Scan an:

  • Logische Lesevorgänge:Die SQL Server-Datenbank-Engine liest eine Seite aus dem Puffercache und verursacht einen logischen Lesevorgang. Unten sehen wir, dass logische Lesevorgänge von 1715 auf 3 reduziert werden, sobald Sie den Index erstellen.
  • Die geschätzten CPU-Kosten sinken ebenfalls von 0,133527 auf 0,00016
  • Geschätzte IO-Kosten sinken von 1,27283 auf 0,003125

Das folgende Bild zeigt den Unterschied zwischen einem Tabellenscan und einer Indexsuche.

Gute (nützliche) Indizes und schlechte Indizes in SQL Server

Wie der Name schon sagt, verbessert ein guter Index die Abfrageleistung und minimiert die Ressourcennutzung. Kann ein Index die Leistung von Abfragen in SQL Server reduzieren? Manchmal erstellen wir den Index für eine bestimmte Spalte, aber er wird nie verwendet. Angenommen, Sie haben einen Index für eine Spalte und führen viele Einfügungen und Aktualisierungen für diese Spalte durch. Für jede Aktualisierung ist auch die entsprechende Indexaktualisierung erforderlich. Wenn Ihre Workload mehr Schreibaktivitäten aufweist und Sie viele Indizes für eine Spalte haben, würde dies die Gesamtleistung Ihrer Abfragen verlangsamen. Ein nicht verwendeter Index kann auch für ausgewählte Anweisungen zu einer langsamen Leistung führen. Der Abfrageoptimierer verwendet Statistiken, um einen Ausführungsplan zu erstellen. Es liest alle Indizes und ihre Datenstichproben und erstellt darauf basierend einen optimierten Abfrageausführungsplan. Sie können Ihre Indexnutzung mithilfe der dynamischen Verwaltungsansicht sys.dm_db_index_usage_stats verfolgen und die Ressourcen überwachen, z. B. Benutzerscans, Benutzersuchen und Benutzersuchen.

SQL Server-Indextypen und Überlegungen

SQL Server verfügt über zwei Hauptindizes – gruppierte und nicht gruppierte Indizes. Ein gruppierter Index speichert die eigentlichen Daten im Blattknoten des Index. Es sortiert die Daten innerhalb der Datenseiten physisch basierend auf dem gruppierten Indexschlüssel. SQL Server lässt einen gruppierten Index pro Tabelle zu. Sie können mehrere Spalten verbinden, um einen gruppierten Indexschlüssel zu erstellen. Ein Non-Clustered-Index ist ein logischer Index und weist die Indexschlüsselspalte auf, die auf den Clustered-Indexschlüssel zeigt.

Wir können auch andere Indizes in SQL Server haben, wie z. B. XML-Index, Spaltenspeicherindex, räumlicher Index, Volltextindex, Hash-Index usw.

Sie sollten die folgenden Punkte berücksichtigen, bevor Sie einen Index in SQL Server erstellen:

  • Arbeitsbelastung
  • Die Spalte, für die der Index erforderlich ist
  • Tabellengröße
  • Aufsteigende oder absteigende Reihenfolge der Spaltendaten
  • Spaltenreihenfolge
  • Indextyp
  • Füllfaktor, Pad-Index und TempDB-Sortierreihenfolge

Vorteile, Auswirkungen und Empfehlungen des SQL Server-Index

Indizes in einer Datenbank können ein zweischneidiges Schwert sein. Ein nützlicher SQL Server-Index verbessert die Abfrage- und Systemleistung, ohne die anderen Abfragen zu beeinträchtigen. Wenn Sie andererseits einen Index ohne Vorbereitung oder Überlegung erstellen, kann dies zu Leistungseinbußen führen, den Datenabruf verlangsamen und kritischere Ressourcen wie CPU, IO und Arbeitsspeicher verbrauchen. Indizes erhöhen auch Ihre Datenbankwartungsaufgaben. Unter Berücksichtigung dieser Faktoren ist es immer am besten, einen geeigneten Index in einer Vorproduktionsumgebung mit der produktionsäquivalenten Workload zu testen, dann die Leistung zu analysieren und zu entscheiden, ob es am besten ist, ihn in einer Produktionsdatenbank zu implementieren. Es gibt noch viele weitere Empfehlungen, die Sie berücksichtigen sollten. Sehen Sie sich meine 11 besten Best Practices für Indizes an, um weitere Einblicke zu erhalten.