--Ein Index ist eine Struktur auf der Festplatte, die einer Tabelle oder Ansicht zugeordnet ist und das Abrufen von Zeilen aus der Tabelle oder Ansicht beschleunigt. Ein Index enthält Schlüssel, die aus einer oder mehreren Spalten einer Tabelle oder Ansicht erstellt werden. Diese Schlüssel werden in einer ausgewogenen Baumstruktur gespeichert, die eine schnelle Suche nach Zeilen anhand ihrer Schlüsselwerte in SQL Server unterstützt.

--Clustered-Indizes sortieren und speichern Datenzeilen in Tabellen oder Ansichten basierend auf ihren Schlüsselwerten. Diese Werte sind die in der Indexdefinition enthaltenen Spalten. Es gibt nur einen Clustered-Index pro Tabelle, da die Datenzeilen nur in einer einzigen Reihenfolge sortiert werden können.
--Datenzeilen in einer Tabelle werden nur dann in Sortierreihenfolge gespeichert, wenn die Tabelle einen Clustered-Index enthält. Wenn eine Tabelle über einen Clustered-Index verfügt, wird die Tabelle als Clustered-Index bezeichnet. Wenn eine Tabelle keinen Clustered-Index hat, werden die Datenzeilen in einer ungeordneten Struktur namens Heap gespeichert.

--Ein nicht gruppierter Index hat genau die gleiche Struktur wie ein gruppierter Index, weist jedoch zwei wichtige Unterschiede auf:
--ein nicht gruppierter Index ändert die physische Reihenfolge der Zeilen in der Tabelle nicht und Blattseiten in einem nicht gruppierten Index bestehen aus Indexschlüsseln und Lesezeichen.

--Clustered-Indizes ermöglichen einen schnelleren Datenabruf als nicht gruppierte Indizes. Normalerweise erweisen sie sich auch bei Aktualisierungen als schneller, nicht jedoch, wenn in der Mitte der Beziehung viele Aktualisierungen an derselben Stelle stattfinden.

– Aus irgendeinem Grund läuft ein Clustered-Index tendenziell schneller als ein Nichtclustered-Index. Wenn das System einen Clustered-Index scannt, ist es nicht erforderlich, die B-Baumstruktur zu verlassen, um Datenseiten zu scannen, da solche Seiten bereits auf der Blattebene des Baums vorhanden sind.

--Ein nicht gruppierter Index erfordert außerdem mehr E/A-Vorgänge als der entsprechende gruppierte Index.

– Der nicht gruppierte Index muss die Datenseiten nach dem Scannen des B-Baums lesen. Wenn ein gruppierter Index für eine oder mehrere andere Spalten der Tabelle vorhanden ist, muss der nicht gruppierte Index die B-Baum-Struktur des gruppierten Index lesen .

– Ein Clustered-Index ist also deutlich schneller als ein Tabellenscan, selbst wenn seine Selektivität ziemlich schlecht ist (die Abfrage gibt viele Zeilen zurück).

TABELLE tsql.dbo.NI ERSTELLEN
ID int NICHT NULL,
T char(8) NULL
);

TABELLE tsql.dbo.NCI ERSTELLEN
ID int NICHT NULL,
T char(8) NULL
);

--Erstellen Sie einen Clustered-Index

CLUSTERED INDEX IX_1 ERSTELLEN
ON tsql.dbo.NCI(ID);

--Erstellen Sie einen nicht gruppierten Index für eine Tabelle

ERSTELLEN SIE NICHT-CLUSTERED INDEX IX_2
ON tsql.dbo.NCI(T);

--Testdaten hinzufügen
DECLARE @i INT = 100000;
DECLARE @t CHAR(1) = "T";

WHILE @i > 0
BEGINNEN
in tsql.dbo.NI Werte einfügen(@i, @t + CAST(@i AS char(6)));
in tsql.dbo.NCI-Werte einfügen(@i, @t + CAST(@i AS char(6)));
SET @i -= 1;
ENDE

--Abfragen für eine Tabelle mit Indizes
WÄHLEN SIE ID, T AUS tsql.dbo.NCI
BESTELLEN NACH ID, T

SELECT ID, COUNT(*) AS C FROM tsql.dbo.NCI
GRUPPE NACH ID, T

WÄHLEN SIE ID, T AUS tsql.dbo.NCI
WO ID > 4000 UND ID< 55000 AND T LIKE "T%"

--Abfrage mit beiden Indizes
VERWENDEN Sie tsql;
SELECT CAST(dbo.NCI.ID AS VARCHAR)
VON dbo.NCI
GRUPPE NACH dbo.NCI.ID
UNION ALLE
SELECT dbo.NCI.T
VON dbo.NCI
GRUPPE NACH dbo.NCI.T

--Indizes-Informationen
SELECT index_type_desc, index_tiefe, index_level,
Seitenanzahl, Datensatzanzahl
VON sys.dm_db_index_physical_stats
(DB_ID(N"tsql"), OBJECT_ID(N"dbo.NCI"), NULL, NULL , "DETAILED");

--Indizes löschen
IF EXISTS (SELECT name FROM sys.indexes
WHERE name = N"IX_1")
DROP INDEX IX_1 ON tsql.dbo.NCI;

IF EXISTS (SELECT name FROM sys.indexes
WHERE name = N"IX_2")
DROP INDEX IX_2 ON tsql.dbo.NCI;

Im vorherigen Artikel haben wir Möglichkeiten zur Optimierung relationaler Datenbanken vorgestellt und diskutiert, wie Clustered- und Nonclustered-Indizes im Zusammenhang mit der Optimierung der Ausführungszeit von Datenbankabfragen funktionieren. Jetzt ist es an der Zeit, dieses Wissen in die Praxis umzusetzen, indem Sie lernen, wie Sie Optimierungsindizes für eine MS SQL-Datenbank erstellen.

Ich möchte Sie an die Definition des Staffs-Tabellenschemas erinnern, mit dem wir arbeiten werden:

Mitarbeitertisch

Nehmen wir an, wir müssen einen nicht gruppierten Index für die Staffs-Tabelle erstellen, der die folgende Abfrage optimiert:

Wählen Sie „ID“, „Name“ und „Job“ aus „Stuffs“ aus, wobei das Gehalt > 1000 und das Foto nicht NULL ist

Der Indexschlüssel sind die Spalten GEHALT und Foto, da die Auswahl nach diesen Feldern gefiltert wird. Und die Spalten „ID“, „Name“ und „Job“ sind die im Index enthaltenen Spalten.

Die allgemeine Befehlssyntax lautet wie folgt:

VERWENDEN GEHEN

NICHTCLUSTERED-INDEX ERSTELLEN AN (ASC – Indexschlüsselspalten)

ENTHALTEN ( -- eingeschlossene Spalten) GO

In unserem Fall sieht die Anfrage so aus:

(Gehalt, Foto) INCLUDE (ID, Name, Job) LOS

Wir haben einen nicht gruppierten Index erstellt. Oder besser gesagt, ein nicht gruppierter Abdeckungsindex. Das bedeutet, dass der Index alle zum Ausführen der Abfrage erforderlichen Felder enthält und SQL Server beim Ausführen der Abfrage nicht auf die Basistabelle zugreift.

Wenn unser Code so wäre:

ERSTELLEN SIE EINEN NICHT KLUSTERIERTEN INDEX IDX_StaffsSearch ON Stuffs

(Gehalt, Foto) INCLUDE (Id) GO

In diesem Fall ist der Index kein abdeckender Index mehr, da er nicht alle in der Abfrage verwendeten Spalten umfasst. Der Optimierer verwendet diesen Index weiterhin bei der Ausführung der Abfrage, seine Effizienz wird jedoch um eine Größenordnung verringert, da er Zugriff auf die Basistabelle benötigt.

Der Clustered-Index wird mit dem folgenden Befehl erstellt:

CLUSTERED INDEX IDX_Stsffsid ON Stuffs (Id) erstellen

Hier wurde ein eindeutiger Clustered-Index basierend auf dem Primärschlüssel der Tabelle (Spalte Id) erstellt.

Echtes Beispiel

Lassen Sie uns nun ein Szenario entwickeln, in dem wir den Grad des Leistungsgewinns bei der Verwendung von Indizes realistisch einschätzen können.

Lassen Sie uns eine neue Datenbank erstellen:

Datenbank TestDB erstellen;

Und eine einzelne Kundentabelle, die aus vier Spalten besteht:

TABELLE ERSTELLEN .(

NICHT NULL, NULL, NULL, NULL) GO

Füllen wir nun unsere Tabelle mit Zufallsdaten. Die Id-Spalte wird in einer Schleife erhöht und die verbleibenden drei Spalten der Tabelle werden mithilfe einer besonderen Version der Zufallsfunktion mit Zufallszahlen gefüllt:

DECLARE @i int = 0;

Während ich< 500000) BEGIN INSERT INTO Customers(Id, Num1, Num2, Num3) VALUES(

@i, abs(checksum(newid())), abs(checksum(newid())), abs(checksum(newid())) SET @i = @i + 1; ENDE

Dieses Skript fügt der Tabelle eine halbe Million Datensätze hinzu. Seien Sie also geduldig, das Skript wird mindestens drei Minuten lang ausgeführt.

Alles ist bereit für den Test. Wir werden die Leistungsmerkmale der Abfrage bewerten. Da die Ausführungszeit der Abfrage von der jeweiligen Maschine abhängen kann, analysieren wir einen unabhängigeren Indikator – die Anzahl der logischen Lesevorgänge.

Um den Statistikerfassungsmodus zu aktivieren, müssen Sie den folgenden Befehl ausführen:

Nach der Ausführung jeder Anfrage haben wir nun auf der Registerkarte „Nachrichten“ Zugriff auf Statistiken zur Ausführung dieser Anfrage, wie unten gezeigt:

Uns interessiert nur der Wert des logischen Leseparameters.

Unsere Tabelle enthält also noch keine Indizes. Lassen Sie uns die folgenden drei Abfragen ausführen und die Anzahl der logischen Lesevorgänge für jede Abfrage in der folgenden Ergebnistabelle aufzeichnen:

1) SELECT Id, Num1, Num2 FROM Customers WHERE Id = 2000

2) SELECT Id, Num1, Num2 FROM Customers WHERE Id >= 0 AND Id< 1000

3) SELECT Id, Num1, Num2 FROM Customers WHERE Id >= 0 AND Id< 5000

Diese Abfragen geben jeweils 1 Zeile, 1000 Zeilen und 5000 Zeilen zurück. Ohne Indizes ist der Leistungsindikator (Anzahl der logischen Lesevorgänge) für alle Abfragen gleich und beträgt 1621. Geben wir die Daten in die Ergebnistabelle ein:

Wir sehen, dass bei der zweiten und dritten Abfrage, wenn eine ziemlich große Anzahl von Zeilen zurückgegeben wird, der von uns erstellte Index die Leistung nicht verbessert hat. Bei einer Abfrage, die eine einzelne Zeile zurückgibt, war die Beschleunigung jedoch enorm. Daraus können wir schließen, dass es sinnvoll ist, nicht abdeckende Indizes zu erstellen, wenn Abfragen optimiert werden, die ein einzelnes Ergebnis zurückgeben.

Lassen Sie uns nun einen abdeckenden Index erstellen und so die maximale Leistung erzielen.

Löschen wir zunächst den vorherigen Index:

VERWENDEN SIE TestDB GO DROP INDEX Customers.TestIndex1

Und erstellen wir einen neuen Index:

CREATE NONCLUSTERED INDEX TestIndex2 ON dbo.Customers(Id) INCLUDE (Num1, Num2);

Lassen Sie uns nun unsere Abfragen ein drittes Mal ausführen und die Ergebnisse in eine Tabelle schreiben:

Keine Indizes
Nicht abdeckender Index
Abdeckindex

Es ist leicht zu erkennen, dass die Leistungssteigerung enorm war. Dadurch haben wir die Geschwindigkeit der Abfrageausführung um das Zehnfache erhöht. Wenn Sie eine Datenbank ausführen, die Millionen von Zeilen speichert, ist dieser Leistungsgewinn deutlich spürbar.

In diesem Artikel haben wir uns ein Beispiel für die Optimierung einer Datenbank durch die Erstellung von Indizes angesehen. Es ist zu beachten, dass die Erstellung von Indizes ein rein individueller Prozess für jede Anfrage ist. Um einen Index zu erstellen, der die Abfrageleistung wirklich optimiert, müssen Sie die Abfrage selbst und ihren Ausführungsplan sorgfältig analysieren.

Eine effiziente Indexerstellung ist eine der besten Möglichkeiten, die Leistung einer Datenbankanwendung zu verbessern. Ohne die Verwendung von Indizes ist SQL Server wie ein Leser, der versucht, ein Wort in einem Buch zu finden, indem er sich jede Seite ansieht. Verfügt das Buch über ein Sachregister (Index), kann der Leser wesentlich schneller nach den benötigten Informationen suchen.

Wenn kein Index vorhanden ist, durchsucht der SQL-Server beim Abrufen von Daten aus einer Tabelle die gesamte Tabelle und überprüft jede Zeile, um festzustellen, ob die Abfragekriterien erfüllt sind. Ein solcher vollständiger Scan kann für die Leistung des gesamten Systems katastrophal sein, insbesondere wenn die Tabellen viele Daten enthalten.

Eine der wichtigsten Aufgaben bei der Arbeit mit einer Datenbank ist die Erstellung eines optimalen Index zur Verbesserung der Systemleistung. Die meisten großen Datenbanken bieten Tools zum Anzeigen des Abfrageausführungsplans und zum Optimieren und Optimieren von Indizes. In diesem Artikel werden einige gute Faustregeln hervorgehoben, die beim Erstellen oder Ändern von Indizes in einer Datenbank gelten. Schauen wir uns zunächst Situationen an, in denen die Indizierung die Leistung verbessert und in denen die Indizierung schädlich sein kann.

Nützliche Indizes

Daher ist die Tabellenindizierung nützlich, wenn Sie mit der Where-Anweisung nach einem bestimmten Datensatz in einer Tabelle suchen. Zu solchen Abfragen gehören beispielsweise Abfragen, die nach einem Wertebereich suchen, Abfragen, die einen genauen Wert einem bestimmten Wert zuordnen, und Abfragen, die zwei Tabellen zusammenführen.

Beispielsweise werden die folgenden Abfragen für die Northwind-Datenbank effizienter ausgeführt, wenn ein Index für die UnitPrice-Spalte erstellt wird.

Aus Produkten löschen, bei denen UnitPrice=1 ist
Wählen Sie * aus Produkten aus, bei denen der Stückpreis zwischen 14 und 16 liegt

Da Indexelemente sortiert gespeichert werden, ist die Indizierung auch beim Erstellen einer Abfrage mithilfe der Order by-Klausel hilfreich. Ohne Index werden Datensätze geladen und sortiert, während die Abfrage ausgeführt wird. Ein auf UnitPrice basierender Index ermöglicht es Ihnen, den Index einfach zu scannen und Zeilen per Referenz abzurufen, wenn Sie die nächste Anfrage verarbeiten. Wenn Sie die Zeilen absteigend sortieren möchten, können Sie den Index einfach in umgekehrter Reihenfolge durchsuchen.

Wählen Sie * Aus der Reihenfolge der Produkte nach UnitPrice ASC

Das Gruppieren eines Datensatzes mithilfe der Group by-Anweisung erfordert häufig auch eine Sortierung. Daher ist die Erstellung eines Index für die Spalte „UnitPrice“ auch für die nächste Abfrage nützlich, die die Anzahl der Einheiten eines Produkts zu jedem bestimmten Preis zählt

Wählen Sie count(*), UnitPrice From Products Group by UnitPrice

Indizes sind nützlich, um einen eindeutigen Wert für eine Spalte beizubehalten, da das DBMS den Index leicht überprüfen kann, um festzustellen, ob der Wert bereits vorhanden ist. Aus diesem Grund werden Primärschlüssel immer indiziert.

Nachteile der Indizierung

Indizes beeinträchtigen die Systemleistung bei Datensatzänderungen. Jedes Mal, wenn eine Abfrage ausgeführt wird, um Daten in einer Tabelle zu ändern, muss sich auch der Index ändern. Um die optimale Anzahl an Indizes auszuwählen, müssen Sie die Datenbank testen und ihre Leistung überwachen. Statische Systeme, in denen Datenbanken hauptsächlich für den Datenabruf, beispielsweise für die Berichterstellung, verwendet werden, können mehr Indizes enthalten, um schreibgeschützte Abfragen zu unterstützen. Datenbanken mit einer großen Anzahl von Transaktionen zum Ändern von Daten benötigen eine kleine Anzahl von Indizes, um einen höheren Durchsatz zu ermöglichen.

Indizes beanspruchen zusätzlichen Speicherplatz auf der Festplatte und im RAM. Die genaue Größe hängt von der Anzahl der Datensätze in der Tabelle sowie von der Anzahl und Größe der Spalten im Index ab. In den meisten Fällen stellt dies kein großes Problem dar, da es heutzutage leicht ist, Speicherplatz für eine bessere Leistung zu opfern.

Erstellen eines optimalen Index

Einfacher Index

Ein einfacher Index ist ein Index, der die Werte eines einzelnen Felds in einer Tabelle verwendet. Die Verwendung eines einfachen Index ist aus zwei Gründen vorteilhaft. Erstens belastet der Betrieb einer Datenbank Ihre Festplatte stark. Große Indexschlüssel zwingen die Datenbank dazu, mehr E/A-Vorgänge auszuführen, was die Leistung einschränkt.

Zweitens sind kleinere Indizes einfacher zu vergleichen, da Indexelemente häufig an Vergleichen beteiligt sind. Aus diesen beiden Gründen ist eine einzelne Ganzzahlspalte ein besserer Index, da sie klein und leicht zu vergleichen ist. Bei Zeichenfolgen hingegen sind zeichenweise Vergleiche und die Beachtung der Parameterbehandlung erforderlich.

Selektiver Index

Die effizientesten Indizes sind diejenigen mit einem geringen Prozentsatz doppelter Werte. Beispielsweise ist ein Telefonbuch für eine Stadt, in der fast jeder den Nachnamen Smith hat, nicht so nützlich, wenn die Einträge darin nach Nachnamen sortiert sind.

Ein Index mit einem hohen Anteil an eindeutigen Werten wird auch als selektiver Index bezeichnet. Offensichtlich weist ein eindeutiger Index die größte Selektivität auf, da er keine doppelten Werte enthält. Viele DBMS können Statistiken zu jedem Index verfolgen und erkennen, wie viele nicht doppelte Werte jeder Index enthält. Diese Statistik wird beim Generieren eines Abfrageausführungsplans verwendet.

Abdeckindizes

Indizes bestehen aus einer Datenspalte, auf der der Index selbst aufgebaut ist, und einem Zeiger auf die entsprechende Zeile. Es ist wie ein Buchindex: Er enthält nur die Schlüsselwörter und einen Link zu einer Seite, auf der Sie weitere Informationen finden. Normalerweise folgt das DBMS Zeigern auf eine Zeile aus dem Index, um alle für die Abfrage erforderlichen Informationen zu sammeln. Wenn der Index jedoch alle in der Abfrage benötigten Spalten enthält, können die Informationen abgerufen werden, ohne auf die Tabelle selbst zuzugreifen.

Betrachten wir einen Index für die UnitPrice-Spalte, die bereits oben erwähnt wurde. Das DBMS kann die Indexelemente nur zum Ausführen der nächsten Abfrage verwenden.

Wählen Sie Count(*), UnitPrice From Products Group by UnitPrice aus

Diese Art von Abfrage wird als abdeckende Abfrage bezeichnet, da alle abgefragten Spalten aus einem einzigen Index abgerufen werden können. Für die wichtigsten Abfragen sollten Sie die Erstellung eines abdeckenden Index in Betracht ziehen, um die bestmögliche Leistung zu erzielen. Solche Indizes sind wahrscheinlich zusammengesetzt (unter Verwendung von mehr als einer Spalte), was das Gegenteil des ersten Prinzips ist: Erstellen Sie einfache Indizes. Offensichtlich kann die Auswahl der optimalen Anzahl von Spalten in einem Index nur durch Testen und Überwachen der Leistung der Datenbank in verschiedenen Situationen beurteilt werden.

Clusterindex

Viele Datenbanken verfügen über einen speziellen Index für eine Tabelle, in dem alle Daten einer Zeile enthalten sind. In SQL Server wird ein solcher Index als Clustered-Index bezeichnet. Ein Clustered-Index kann mit einem Telefonbuch verglichen werden, da jedes Indexelement alle benötigten Informationen enthält und keine Links zum Abrufen zusätzlicher Daten enthält.

Es gibt eine allgemeine Regel: Jede nicht triviale Tabelle muss einen Clustered-Index haben. Wenn es möglich ist, nur einen Index für eine Tabelle zu erstellen, gruppieren Sie ihn. Wenn in SQL Server ein Primärschlüssel erstellt wird, wird automatisch ein Clustered-Index erstellt (sofern dieser noch keinen enthält), wobei die Primärschlüsselspalte als Indexierungsschlüssel verwendet wird. Ein Clustered-Index ist der effizienteste Index (wenn er verwendet wird, deckt er die gesamte Abfrage ab) und in vielen DBMS hilft ein solcher Index dabei, den zum Speichern von Tabellen erforderlichen Speicherplatz effektiv zu verwalten, da ansonsten (ohne Erstellung eines Clustered-Index) Tabellenzeilen darin gespeichert werden eine ungeordnete Struktur, die als Heap bezeichnet wird.

Seien Sie vorsichtig, wenn Sie Spalten für einen Clustered-Index auswählen. Wenn Sie einen Datensatz und den Wert einer Spalte in einem Clustered-Index ändern, wird die Datenbank gezwungen, die Indexelemente neu zu erstellen (um sie in sortierter Reihenfolge zu halten). Denken Sie daran, dass die Indexelemente für einen Clustered-Index alle Spaltenwerte enthalten. Daher ist das Ändern des Werts einer Spalte vergleichbar mit dem Ausführen einer Delete-Anweisung gefolgt von einer Insert-Anweisung, was bei häufiger Ausführung offensichtlich zu Leistungsproblemen führt. Aus diesem Grund bestehen Clustered-Indizes häufig aus einer Primärschlüssel- und einer Fremdschlüsselspalte. Wenn sich Schlüsselwerte ändern, ändern sie sich nur sehr selten.

Abschluss

Die Bestimmung der richtigen Indizes für die Verwendung in einer Datenbank erfordert eine sorgfältige Analyse und Prüfung des Systems. Die in diesem Artikel vorgestellten Vorgehensweisen sind gute Regeln für die Erstellung von Indizes. Nachdem Sie diese Methoden angewendet haben, müssen Sie Ihre spezifische Anwendung unter Ihren spezifischen Hardware-, Speicher- und Betriebsbedingungen erneut testen.

Eine der wichtigsten Möglichkeiten, eine hohe Produktivität zu erreichen SQL Server ist die Verwendung von Indizes. Ein Index beschleunigt den Abfrageprozess, indem er einen schnellen Zugriff auf Datenzeilen in einer Tabelle ermöglicht, ähnlich wie ein Index in einem Buch Ihnen dabei hilft, die benötigten Informationen schnell zu finden. In diesem Artikel gebe ich einen kurzen Überblick über Indizes in SQL Server und erklären Sie, wie sie in der Datenbank organisiert sind und wie sie dazu beitragen, Datenbankabfragen zu beschleunigen.

Indizes werden für Tabellen- und Ansichtsspalten erstellt. Indizes bieten eine Möglichkeit, Daten basierend auf den Werten in diesen Spalten schnell zu durchsuchen. Wenn Sie beispielsweise einen Index für einen Primärschlüssel erstellen und dann mithilfe der Primärschlüsselwerte nach einer Datenzeile suchen, dann SQL Server sucht zuerst den Indexwert und verwendet dann den Index, um schnell die gesamte Datenzeile zu finden. Ohne Index wird ein vollständiger Scan aller Zeilen in der Tabelle durchgeführt, was erhebliche Auswirkungen auf die Leistung haben kann.
Sie können für die meisten Spalten in einer Tabelle oder Ansicht einen Index erstellen. Die Ausnahme bilden hauptsächlich Spalten mit Datentypen zum Speichern großer Objekte ( LOB), solche wie Bild, Text oder varchar(max). Sie können auch Indizes für Spalten erstellen, die zum Speichern von Daten im Format dienen XML, aber diese Indizes sind etwas anders strukturiert als die Standardindizes und ihre Betrachtung würde den Rahmen dieses Artikels sprengen. Außerdem wird in dem Artikel nicht darauf eingegangen Columnstore Indizes. Stattdessen konzentriere ich mich auf die Indizes, die in Datenbanken am häufigsten verwendet werden SQL Server.
Ein Index besteht aus einer Reihe von Seiten, Indexknoten, die in einer Baumstruktur organisiert sind – ausgeglichener Baum. Diese Struktur ist hierarchischer Natur und beginnt mit einem Wurzelknoten oben in der Hierarchie und Blattknoten, den Blättern, unten, wie in der Abbildung dargestellt:


Wenn Sie eine indizierte Spalte abfragen, beginnt die Abfrage-Engine oben am Stammknoten und arbeitet sich nach unten durch die Zwischenknoten, wobei jede Zwischenschicht detailliertere Informationen zu den Daten enthält. Die Abfrage-Engine bewegt sich weiter durch die Indexknoten, bis sie mit den Indexblättern die unterste Ebene erreicht. Wenn Sie beispielsweise in einer indizierten Spalte nach dem Wert 123 suchen, ermittelt die Abfrage-Engine zunächst die Seite auf der ersten Zwischenebene auf der Stammebene. In diesem Fall zeigt die erste Seite auf einen Wert zwischen 1 und 100 und die zweite auf einen Wert zwischen 101 und 200, sodass die Abfrage-Engine auf die zweite Seite dieser Zwischenebene zugreift. Als nächstes werden Sie sehen, dass Sie zur dritten Seite der nächsten Zwischenstufe wechseln sollten. Von hier aus liest das Abfragesubsystem den Wert des Index selbst auf einer niedrigeren Ebene. Indexblätter können je nach Indextyp entweder die Tabellendaten selbst oder einfach einen Zeiger auf Zeilen mit Daten in der Tabelle enthalten: Clustered-Index oder Nonclustered-Index.

Clustered-Index

Ein Clustered-Index speichert die tatsächlichen Datenzeilen in den Blättern des Index. Zurück zum vorherigen Beispiel bedeutet dies, dass die mit dem Schlüsselwert 123 verknüpfte Datenzeile im Index selbst gespeichert wird. Ein wichtiges Merkmal eines Clustered-Index besteht darin, dass alle Werte in einer bestimmten Reihenfolge sortiert werden, entweder aufsteigend oder absteigend. Daher kann eine Tabelle oder Ansicht nur einen Clustered-Index haben. Darüber hinaus ist zu beachten, dass Daten in einer Tabelle nur dann in sortierter Form gespeichert werden, wenn für diese Tabelle ein Clustered-Index erstellt wurde.
Eine Tabelle, die keinen Clustered-Index hat, wird als Heap bezeichnet.

Nicht gruppierter Index

Im Gegensatz zu einem Clustered-Index enthalten die Blätter eines Nonclustered-Index nur die Spalten ( Schlüssel), anhand derer dieser Index bestimmt wird, und enthält außerdem einen Zeiger auf Zeilen mit echten Daten in der Tabelle. Dies bedeutet, dass das Unterabfragesystem einen zusätzlichen Vorgang erfordert, um die erforderlichen Daten zu finden und abzurufen. Der Inhalt des Datenzeigers hängt davon ab, wie die Daten gespeichert werden: Clustertabelle oder Heap. Wenn ein Zeiger auf eine gruppierte Tabelle zeigt, zeigt er auf einen gruppierten Index, der zum Auffinden der tatsächlichen Daten verwendet werden kann. Wenn sich ein Zeiger auf einen Heap bezieht, zeigt er auf eine bestimmte Datenzeilenkennung. Nicht gruppierte Indizes können nicht wie gruppierte Indizes sortiert werden, Sie können jedoch mehr als einen nicht gruppierten Index für eine Tabelle oder Ansicht erstellen, bis zu 999. Dies bedeutet nicht, dass Sie so viele Indizes wie möglich erstellen sollten. Indizes können die Systemleistung entweder verbessern oder verschlechtern. Zusätzlich zur Möglichkeit, mehrere nicht gruppierte Indizes zu erstellen, können Sie auch zusätzliche Spalten einschließen ( enthaltene Spalte) in seinen Index: Die Blätter des Index speichern nicht nur den Wert der indizierten Spalten selbst, sondern auch die Werte dieser nicht indizierten zusätzlichen Spalten. Mit diesem Ansatz können Sie einige der dem Index auferlegten Einschränkungen umgehen. Sie können beispielsweise eine nicht indizierbare Spalte einschließen oder die Indexlängenbeschränkung (in den meisten Fällen 900 Byte) umgehen.

Arten von Indizes

Er ist nicht nur ein gruppierter oder nicht gruppierter Index, sondern kann auch als zusammengesetzter Index, eindeutiger Index oder abdeckender Index konfiguriert werden.

Composite-Index

Ein solcher Index kann mehr als eine Spalte enthalten. Sie können bis zu 16 Spalten in einen Index aufnehmen, ihre Gesamtlänge ist jedoch auf 900 Byte begrenzt. Sowohl gruppierte als auch nicht gruppierte Indizes können zusammengesetzt sein.

Eindeutiger Index

Dieser Index stellt sicher, dass jeder Wert in der indizierten Spalte eindeutig ist. Wenn der Index zusammengesetzt ist, gilt die Eindeutigkeit für alle Spalten im Index, jedoch nicht für jede einzelne Spalte. Wenn Sie beispielsweise einen eindeutigen Index für die Spalten erstellen NAME Und NACHNAME, dann muss der vollständige Name eindeutig sein, Duplikate im Vor- oder Nachnamen sind jedoch möglich.
Ein eindeutiger Index wird automatisch erstellt, wenn Sie eine Spalteneinschränkung definieren: Primärschlüssel oder Eindeutigkeitswert-Einschränkung:

• Primärschlüssel
  Wenn Sie dann eine Primärschlüsseleinschränkung für eine oder mehrere Spalten definieren SQL Server erstellt automatisch einen eindeutigen Clustered-Index, wenn zuvor noch kein Clustered-Index erstellt wurde (in diesem Fall wird ein eindeutiger Nicht-Clustered-Index für den Primärschlüssel erstellt).
• Einzigartigkeit der Werte
  Wenn Sie dann eine Einschränkung für die Eindeutigkeit von Werten definieren SQL Server erstellt automatisch einen eindeutigen, nicht gruppierten Index. Sie können angeben, dass ein eindeutiger Clustered-Index erstellt wird, wenn für die Tabelle noch kein Clustered-Index erstellt wurde

Abdeckindex

Ein solcher Index ermöglicht es einer bestimmten Abfrage, sofort alle erforderlichen Daten aus den Blättern des Index abzurufen, ohne zusätzlich auf die Datensätze der Tabelle selbst zugreifen zu müssen.

Entwerfen von Indizes

So nützlich Indizes auch sein können, sie müssen sorgfältig entworfen werden. Da Indizes viel Speicherplatz beanspruchen können, sollten Sie nicht mehr Indizes als nötig erstellen. Darüber hinaus werden Indizes automatisch aktualisiert, wenn die Datenzeile selbst aktualisiert wird, was zu zusätzlichem Ressourcenaufwand und Leistungseinbußen führen kann. Beim Entwerfen von Indizes müssen verschiedene Überlegungen zur Datenbank und zu Abfragen berücksichtigt werden.

Datenbank

Wie bereits erwähnt, können Indizes die Systemleistung verbessern, weil Sie bieten der Abfrage-Engine eine schnelle Möglichkeit, Daten zu finden. Sie sollten jedoch auch berücksichtigen, wie oft Sie Daten einfügen, aktualisieren oder löschen möchten. Wenn Sie Daten ändern, müssen auch die Indizes geändert werden, um die entsprechenden Aktionen für die Daten widerzuspiegeln, was die Systemleistung erheblich beeinträchtigen kann. Berücksichtigen Sie bei der Planung Ihrer Indexierungsstrategie die folgenden Richtlinien:

• Verwenden Sie für Tabellen, die häufig aktualisiert werden, so wenige Indizes wie möglich.
• Wenn die Tabelle eine große Datenmenge enthält, die Änderungen jedoch geringfügig sind, verwenden Sie so viele Indizes wie nötig, um die Leistung Ihrer Abfragen zu verbessern. Denken Sie jedoch sorgfältig darüber nach, bevor Sie Indizes für kleine Tabellen verwenden, denn ... Es ist möglich, dass die Verwendung einer Indexsuche länger dauert als das einfache Durchsuchen aller Zeilen.
• Versuchen Sie bei Clustered-Indizes, die Felder so kurz wie möglich zu halten. Der beste Ansatz besteht darin, einen Clustered-Index für Spalten zu verwenden, die eindeutige Werte haben und NULL nicht zulassen. Aus diesem Grund wird ein Primärschlüssel häufig als Clustered-Index verwendet.
• Die Eindeutigkeit der Werte in einer Spalte beeinflusst die Leistung des Index. Im Allgemeinen gilt: Je mehr Duplikate eine Spalte enthält, desto schlechter ist die Leistung des Index. Andererseits ist die Leistung des Index umso besser, je mehr eindeutige Werte vorhanden sind. Verwenden Sie nach Möglichkeit einen eindeutigen Index.
• Berücksichtigen Sie bei einem zusammengesetzten Index die Reihenfolge der Spalten im Index. Spalten, die in Ausdrücken verwendet werden WO(z.B, WHERE FirstName = „Charlie“) muss im Index an erster Stelle stehen. Nachfolgende Spalten sollten nach der Eindeutigkeit ihrer Werte aufgelistet werden (Spalten mit der höchsten Anzahl eindeutiger Werte stehen an erster Stelle).
• Sie können auch einen Index für berechnete Spalten angeben, wenn diese bestimmte Anforderungen erfüllen. Beispielsweise müssen Ausdrücke, die zum Erhalten des Werts einer Spalte verwendet werden, deterministisch sein (immer das gleiche Ergebnis für einen bestimmten Satz von Eingabeparametern zurückgeben).

Datenbankabfragen

Eine weitere Überlegung beim Entwerfen von Indizes ist, welche Abfragen für die Datenbank ausgeführt werden. Wie bereits erwähnt, müssen Sie berücksichtigen, wie oft sich die Daten ändern. Darüber hinaus sollten die folgenden Grundsätze angewendet werden:

• Versuchen Sie, so viele Zeilen wie möglich in einer Abfrage einzufügen oder zu ändern, anstatt dies in mehreren einzelnen Abfragen zu tun.
• Erstellen Sie einen nicht gruppierten Index für Spalten, die häufig als Suchbegriffe in Ihren Abfragen verwendet werden. WO und Verbindungen in VERBINDEN.
• Erwägen Sie die Indizierung von Spalten, die in Zeilensuchabfragen verwendet werden, um exakte Wertübereinstimmungen zu erzielen.

Und jetzt tatsächlich:

14 Fragen zu Indizes in SQL Server, die Sie nicht stellen konnten

Warum kann eine Tabelle nicht zwei Clustered-Indizes haben?

Möchten Sie eine kurze Antwort? Ein Clustered-Index ist eine Tabelle. Wenn Sie einen Clustered-Index für eine Tabelle erstellen, sortiert die Speicher-Engine alle Zeilen in der Tabelle entsprechend der Indexdefinition in aufsteigender oder absteigender Reihenfolge. Ein Clustered-Index ist keine separate Einheit wie andere Indizes, sondern ein Mechanismus zum Sortieren von Daten in einer Tabelle und zum Ermöglichen des schnellen Zugriffs auf Datenzeilen.
Stellen Sie sich vor, Sie hätten eine Tabelle mit der Historie der Verkaufstransaktionen. Die Verkaufstabelle enthält Informationen wie Bestell-ID, Produktposition in der Bestellung, Produktnummer, Produktmenge, Bestellnummer und -datum usw. Sie erstellen einen Clustered-Index für Spalten Auftragsnummer Und Leitungs-ID, aufsteigend sortiert, wie im Folgenden dargestellt T-SQL Code:
EINZIGARTIGEN CLUSTERED INDEX ERSTELLEN ix_oriderid_lineid ON dbo.Sales(OrderID, LineID);
Wenn Sie dieses Skript ausführen, werden alle Zeilen in der Tabelle zuerst physisch nach der OrderID-Spalte und dann nach LineID sortiert, die Daten selbst bleiben jedoch in einem einzigen logischen Block, der Tabelle. Aus diesem Grund können Sie nicht zwei Clustered-Indizes erstellen. Es kann nur eine Tabelle mit einem Datenwert geben und diese Tabelle kann nur einmal in einer bestimmten Reihenfolge sortiert werden.

Wenn eine gruppierte Tabelle viele Vorteile bietet, warum dann einen Heap verwenden?

Sie haben Recht. Clustered-Tabellen sind großartig und die meisten Ihrer Abfragen werden bei Tabellen mit einem Clustered-Index besser funktionieren. In manchen Fällen möchten Sie die Tische jedoch möglicherweise in ihrem natürlichen, makellosen Zustand belassen, d. h. in Form eines Heaps und erstellen Sie nur nicht gruppierte Indizes, um Ihre Abfragen am Laufen zu halten.
Wie Sie sich erinnern, speichert der Heap Daten in zufälliger Reihenfolge. Normalerweise fügt das Speichersubsystem Daten in der Reihenfolge zu einer Tabelle hinzu, in der sie eingefügt werden, aber das Speichersubsystem verschiebt Zeilen auch gerne, um die Speicherung effizienter zu gestalten. Dadurch haben Sie keine Möglichkeit vorherzusagen, in welcher Reihenfolge die Daten gespeichert werden.
Wenn die Abfrage-Engine Daten ohne die Vorteile eines nicht gruppierten Indexes finden muss, führt sie einen vollständigen Scan der Tabelle durch, um die benötigten Zeilen zu finden. Bei sehr kleinen Tabellen ist dies normalerweise kein Problem, aber wenn der Heap größer wird, sinkt die Leistung schnell. Natürlich kann ein nicht gruppierter Index hilfreich sein, indem er einen Zeiger auf die Datei, Seite und Zeile verwendet, in der die erforderlichen Daten gespeichert sind – dies ist normalerweise eine viel bessere Alternative zu einem Tabellenscan. Dennoch ist es schwierig, die Vorteile eines Clustered-Index zu vergleichen, wenn man die Abfrageleistung berücksichtigt.
Allerdings kann der Heap in bestimmten Situationen dazu beitragen, die Leistung zu verbessern. Stellen Sie sich eine Tabelle mit vielen Einfügungen, aber wenigen Aktualisierungen oder Löschungen vor. Beispielsweise wird eine Tabelle, in der ein Protokoll gespeichert wird, hauptsächlich zum Einfügen von Werten verwendet, bis sie archiviert wird. Auf dem Heap kommt es nicht zu Paging und Datenfragmentierung wie bei einem Clustered-Index, da die Zeilen einfach am Ende des Heaps hinzugefügt werden. Eine zu starke Aufteilung der Seiten kann erhebliche Auswirkungen auf die Leistung haben, und zwar nicht im positiven Sinne. Im Allgemeinen ermöglicht Ihnen der Heap das relativ problemlose Einfügen von Daten und Sie müssen sich nicht mit dem Speicher- und Wartungsaufwand befassen, der bei einem Clustered-Index anfällt.
Das Fehlen von Aktualisierungen und Löschungen von Daten sollte jedoch nicht als einziger Grund angesehen werden. Auch die Art und Weise der Datenerhebung ist ein wichtiger Faktor. Sie sollten beispielsweise keinen Heap verwenden, wenn Sie häufig Datenbereiche abfragen oder die abgefragten Daten häufig sortiert oder gruppiert werden müssen.
Dies bedeutet lediglich, dass Sie die Verwendung des Heaps nur dann in Betracht ziehen sollten, wenn Sie mit sehr kleinen Tabellen arbeiten oder sich Ihre gesamte Interaktion mit der Tabelle auf das Einfügen von Daten beschränkt und Ihre Abfragen äußerst einfach sind (und Sie nicht gruppierte Indizes verwenden). Trotzdem). Ansonsten bleiben Sie bei einem gut gestalteten Clustered-Index, etwa einem, der auf einem einfachen aufsteigenden Schlüsselfeld definiert ist, etwa einer weit verbreiteten Spalte mit IDENTITÄT.

Wie ändere ich den Standard-Indexfüllfaktor?

Das Ändern des standardmäßigen Indexfüllfaktors ist eine Sache. Zu verstehen, wie das Standardverhältnis funktioniert, ist eine andere Sache. Aber gehen Sie zunächst ein paar Schritte zurück. Der Indexfüllfaktor bestimmt den Platz auf der Seite, um den Index auf der untersten Ebene (Blattebene) zu speichern, bevor mit dem Füllen einer neuen Seite begonnen wird. Wenn der Koeffizient beispielsweise auf 90 eingestellt ist, nimmt der Index bei steigendem Index 90 % der Seite ein und wechselt dann zur nächsten Seite.
Standardmäßig ist der Indexfüllfaktorwert in SQL Server ist 0, was dasselbe wie 100 ist. Daher erben alle neuen Indizes automatisch diese Einstellung, es sei denn, Sie geben in Ihrem Code ausdrücklich einen Wert an, der vom Systemstandardwert abweicht, oder ändern das Standardverhalten. Sie können verwenden SQL Server Management Studio um den Standardwert anzupassen oder eine gespeicherte Systemprozedur auszuführen sp_configure. Zum Beispiel der folgende Satz T-SQL Befehle setzen den Koeffizientenwert auf 90 (Sie müssen zuerst in den erweiterten Einstellungsmodus wechseln):
EXEC sp_configure „erweiterte Optionen anzeigen“, 1; GEHEN SIE NEU KONFIGURIEREN; GO EXEC sp_configure "Füllfaktor", 90; GEHEN SIE NEU KONFIGURIEREN; GEHEN
Nachdem Sie den Wert des Indexfüllfaktors geändert haben, müssen Sie den Dienst neu starten SQL Server. Sie können den eingestellten Wert jetzt überprüfen, indem Sie sp_configure ohne das angegebene zweite Argument ausführen:
EXEC sp_configure „Füllfaktor“ GO
Dieser Befehl sollte einen Wert von 90 zurückgeben. Daher verwenden alle neu erstellten Indizes diesen Wert. Sie können dies testen, indem Sie einen Index erstellen und den Füllfaktorwert abfragen:
VERWENDEN Sie AdventureWorks2012; -- Ihre Datenbank GO CREATE NONCLUSTERED INDEX ix_people_lastname ON Person.Person(LastName); GO SELECT fill_factor FROM sys.indexes WHERE object_id = object_id("Person.Person") AND name="ix_people_lastname";
In diesem Beispiel haben wir einen nicht gruppierten Index für eine Tabelle erstellt Person in der Datenbank AdventureWorks2012. Nachdem wir den Index erstellt haben, können wir den Füllfaktorwert aus den Systemtabellen sys.indexes abrufen. Die Abfrage sollte 90 zurückgeben.
Stellen wir uns jedoch vor, dass wir den Index gelöscht und erneut erstellt haben, jetzt aber einen bestimmten Füllfaktorwert angegeben haben:
CREATE NONCLUSTERED INDEX ix_people_lastname ON Person.Person(LastName) WITH (fillfactor=80); GO SELECT fill_factor FROM sys.indexes WHERE object_id = object_id("Person.Person") AND name="ix_people_lastname";
Dieses Mal haben wir Anweisungen hinzugefügt MIT und Option Füllfaktor für unsere Indexerstellung INDEX ERSTELLEN und den Wert 80 angegeben. Operator WÄHLEN gibt nun den entsprechenden Wert zurück.
Bisher war alles ziemlich einfach. Wenn Sie in diesem gesamten Prozess einen Index erstellen, der einen Standardkoeffizientenwert verwendet, können Sie sich wirklich verbrennen, vorausgesetzt, Sie kennen diesen Wert. Jemand bastelt beispielsweise an den Servereinstellungen herum und ist so stur, dass er den Indexfüllfaktor auf 20 setzt. In der Zwischenzeit erstellen Sie weiterhin Indizes, vorausgesetzt, der Standardwert ist 0. Leider haben Sie keine Möglichkeit, die Füllung herauszufinden Faktor bis, solange Sie keinen Index erstellen und dann den Wert überprüfen, wie wir es in unseren Beispielen getan haben. Andernfalls müssen Sie auf den Moment warten, in dem die Abfrageleistung so stark abnimmt, dass Sie anfangen, etwas zu vermuten.
Ein weiteres Problem, das Sie beachten sollten, ist die Neuerstellung von Indizes. Wie beim Erstellen eines Index können Sie den Indexfüllfaktorwert angeben, wenn Sie ihn neu erstellen. Im Gegensatz zum Befehl „Index erstellen“ verwendet Rebuild jedoch nicht die Standardeinstellungen des Servers, auch wenn es den Anschein hat. Dies gilt umso mehr, wenn Sie den Wert des Indexfüllfaktors nicht speziell angeben SQL Server wird den Wert des Koeffizienten verwenden, mit dem dieser Index vor seiner Umstrukturierung existierte. Zum Beispiel die folgende Operation INDEX ÄNDERN baut den Index, den wir gerade erstellt haben, neu auf:
ALTER INDEX ix_people_lastname ON Person.Person REBUILD; GO SELECT fill_factor FROM sys.indexes WHERE object_id = object_id("Person.Person") AND name="ix_people_lastname";
Wenn wir den Füllfaktorwert überprüfen, erhalten wir einen Wert von 80, da wir diesen Wert bei der letzten Indexerstellung angegeben haben. Der Standardwert wird ignoriert.
Wie Sie sehen, ist das Ändern des Indexfüllfaktorwerts nicht so schwierig. Es ist viel schwieriger, den aktuellen Wert zu kennen und zu verstehen, wann er angewendet wird. Wenn Sie den Koeffizienten beim Erstellen und Neuerstellen von Indizes immer konkret angeben, kennen Sie immer das konkrete Ergebnis. Es sei denn, Sie müssen sich Sorgen machen, dass nicht noch einmal jemand anderes die Servereinstellungen verfälscht, was zur Folge hat, dass alle Indizes mit einem lächerlich niedrigen Indexfüllfaktor neu erstellt werden.

Ist es möglich, einen Clustered-Index für eine Spalte zu erstellen, die Duplikate enthält?

Ja und nein. Ja, Sie können einen Clustered-Index für eine Schlüsselspalte erstellen, die doppelte Werte enthält. Nein, der Wert einer Schlüsselspalte darf nicht in einem nicht eindeutigen Zustand bleiben. Lassen Sie mich erklären. Wenn Sie einen nicht eindeutigen Clustered-Index für eine Spalte erstellen, fügt die Speicher-Engine dem doppelten Wert einen Eindeutiger hinzu, um die Eindeutigkeit sicherzustellen und somit jede Zeile in der Cluster-Tabelle identifizieren zu können.
Beispielsweise könnten Sie beschließen, einen gruppierten Index für eine Spalte mit Kundendaten zu erstellen Familienname, Nachname den Nachnamen behalten. Die Spalte enthält die Werte Franklin, Hancock, Washington und Smith. Anschließend fügt man wieder die Werte Adams, Hancock, Smith und Smith ein. Da der Wert der Schlüsselspalte jedoch eindeutig sein muss, ändert die Speicher-Engine den Wert der Duplikate so, dass sie etwa so aussehen: Adams, Franklin, Hancock, Hancock1234, Washington, Smith, Smith4567 und Smith5678.
Auf den ersten Blick scheint dieser Ansatz in Ordnung zu sein, aber ein ganzzahliger Wert erhöht die Größe des Schlüssels, was bei einer großen Anzahl von Duplikaten zum Problem werden kann und diese Werte zur Grundlage eines nicht gruppierten Index oder eines Fremdindex werden Schlüsselreferenz. Aus diesen Gründen sollten Sie nach Möglichkeit immer versuchen, eindeutige Clustered-Indizes zu erstellen. Wenn dies nicht möglich ist, versuchen Sie zumindest, Spalten mit einem sehr hohen eindeutigen Wertinhalt zu verwenden.

Wie wird die Tabelle gespeichert, wenn kein Clustered-Index erstellt wurde?

SQL Server unterstützt zwei Arten von Tabellen: gruppierte Tabellen mit einem gruppierten Index und Heap-Tabellen oder nur Heaps. Im Gegensatz zu Cluster-Tabellen werden die Daten auf dem Heap in keiner Weise sortiert. Im Wesentlichen handelt es sich dabei um einen Datenhaufen. Wenn Sie einer solchen Tabelle eine Zeile hinzufügen, hängt die Speicher-Engine diese einfach am Ende der Seite an. Wenn die Seite mit Daten gefüllt ist, werden sie einer neuen Seite hinzugefügt. In den meisten Fällen möchten Sie einen Clustered-Index für eine Tabelle erstellen, um die Sortierbarkeit und Abfragegeschwindigkeit zu nutzen (stellen Sie sich vor, Sie suchen nach einer Telefonnummer in einem unsortierten Adressbuch). Wenn Sie jedoch keinen gruppierten Index erstellen möchten, können Sie dennoch einen nicht gruppierten Index auf dem Heap erstellen. In diesem Fall verfügt jede Indexzeile über einen Zeiger auf eine Heapzeile. Der Index umfasst die Datei-ID, die Seitennummer und die Datenzeilennummer.

Welche Beziehung besteht zwischen Werteindeutigkeitsbeschränkungen und einem Primärschlüssel mit Tabellenindizes?

Ein Primärschlüssel und eine eindeutige Einschränkung stellen sicher, dass die Werte in einer Spalte eindeutig sind. Sie können für eine Tabelle nur einen Primärschlüssel erstellen und dieser darf keine Werte enthalten NULL. Sie können mehrere Einschränkungen für die Eindeutigkeit eines Werts für eine Tabelle erstellen, und jede davon kann einen einzelnen Datensatz haben NULL.
Wenn Sie einen Primärschlüssel erstellen, erstellt die Speicher-Engine auch einen eindeutigen Clustered-Index, sofern noch kein Clustered-Index erstellt wurde. Sie können das Standardverhalten jedoch überschreiben und es wird ein nicht gruppierter Index erstellt. Wenn beim Erstellen des Primärschlüssels ein gruppierter Index vorhanden ist, wird ein eindeutiger nicht gruppierter Index erstellt.
Wenn Sie eine eindeutige Einschränkung erstellen, erstellt die Speicher-Engine einen eindeutigen, nicht gruppierten Index. Sie können jedoch die Erstellung eines eindeutigen Clustered-Index angeben, sofern noch keiner erstellt wurde.
Im Allgemeinen sind eine Eindeutigkeitswertbeschränkung und ein Eindeutigkeitsindex dasselbe.

Warum werden gruppierte und nicht gruppierte Indizes in SQL Server als B-Tree bezeichnet?

Grundlegende Indizes in SQL Server, gruppiert oder nicht gruppiert, werden über Gruppen von Seiten verteilt, die als Indexknoten bezeichnet werden. Diese Seiten sind in einer bestimmten Hierarchie mit einer Baumstruktur organisiert, die als ausgeglichener Baum bezeichnet wird. Auf der obersten Ebene befindet sich der Wurzelknoten, auf der unteren die Blattknoten, mit Zwischenknoten zwischen der oberen und der unteren Ebene, wie in der Abbildung dargestellt:


Der Stammknoten stellt den Haupteinstiegspunkt für Abfragen dar, die versuchen, Daten über den Index abzurufen. Ausgehend von diesem Knoten initiiert die Abfrage-Engine eine Navigation entlang der hierarchischen Struktur zum entsprechenden Blattknoten, der die Daten enthält.
Stellen Sie sich zum Beispiel vor, dass eine Anfrage zur Auswahl von Zeilen mit einem Schlüsselwert von 82 eingegangen ist. Das Abfragesubsystem beginnt mit der Arbeit am Wurzelknoten, der auf einen geeigneten Zwischenknoten verweist, in unserem Fall 1-100. Vom Zwischenknoten 1-100 erfolgt ein Übergang zum Knoten 51-100 und von dort zum Endknoten 76-100. Wenn es sich um einen Clustered-Index handelt, enthält das Knotenblatt die Daten der Zeile, die dem Schlüssel gleich 82 zugeordnet ist. Wenn es sich um einen Nicht-Clustered-Index handelt, enthält das Indexblatt einen Zeiger auf die Clustered-Tabelle oder eine bestimmte Zeile in der Haufen.

Wie kann ein Index die Abfrageleistung überhaupt verbessern, wenn Sie alle diese Indexknoten durchlaufen müssen?

Erstens verbessern Indizes nicht immer die Leistung. Zu viele falsch erstellte Indizes verwandeln das System in einen Sumpf und beeinträchtigen die Abfrageleistung. Genauer gesagt lässt sich sagen, dass Indizes bei sorgfältiger Anwendung erhebliche Leistungssteigerungen bewirken können.
Stellen Sie sich ein riesiges Buch zum Thema Leistungsoptimierung vor SQL Server(Papierversion, keine elektronische Version). Stellen Sie sich vor, Sie möchten Informationen zur Konfiguration von Resource Governor finden. Sie können mit dem Finger Seite für Seite durch das gesamte Buch ziehen oder das Inhaltsverzeichnis öffnen und die genaue Seitenzahl mit den gesuchten Informationen herausfinden (vorausgesetzt, das Buch ist korrekt indexiert und die Inhalte verfügen über die richtigen Indexe). Dies spart Ihnen sicherlich viel Zeit, auch wenn Sie zunächst auf eine völlig andere Struktur (den Index) zugreifen müssen, um die benötigten Informationen aus der Primärstruktur (dem Buch) zu erhalten.
Wie ein Buchindex, ein Index in SQL Server ermöglicht Ihnen die Durchführung präziser Abfragen der benötigten Daten, anstatt alle in einer Tabelle enthaltenen Daten vollständig zu scannen. Bei kleinen Tabellen ist ein vollständiger Scan in der Regel kein Problem, große Tabellen nehmen jedoch viele Datenseiten in Anspruch, was zu einer erheblichen Ausführungszeit der Abfrage führen kann, sofern kein Index vorhanden ist, der es der Abfrage-Engine ermöglicht, sofort den richtigen Speicherort der Daten zu ermitteln. Stellen Sie sich vor, Sie verirren sich ohne Karte an einer mehrstöckigen Straßenkreuzung vor einer großen Metropole und Sie werden auf die Idee kommen.

Wenn Indizes so großartig sind, warum erstellen Sie dann nicht einfach einen für jede Spalte?

Keine gute Tat sollte ungestraft bleiben. Zumindest ist das bei Indizes der Fall. Natürlich funktionieren Indizes hervorragend, solange Sie Operator-Abrufabfragen ausführen WÄHLEN, aber sobald häufige Anrufe bei den Betreibern beginnen EINFÜGEN, AKTUALISIEREN Und LÖSCHEN, sodass sich die Landschaft sehr schnell ändert.
Wenn Sie eine Datenanfrage durch den Betreiber initiieren WÄHLEN, findet die Abfrage-Engine den Index, durchläuft seine Baumstruktur und entdeckt die gesuchten Daten. Was könnte einfacher sein? Aber die Dinge ändern sich, wenn Sie eine Änderungserklärung initiieren wie AKTUALISIEREN. Ja, für den ersten Teil der Anweisung kann die Abfrage-Engine erneut den Index verwenden, um die geänderte Zeile zu finden – das sind gute Nachrichten. Und wenn es eine einfache Datenänderung in einer Zeile gibt, die sich nicht auf Änderungen in Schlüsselspalten auswirkt, ist der Änderungsprozess völlig schmerzlos. Was aber, wenn die Änderung dazu führt, dass die Seiten, die die Daten enthalten, aufgeteilt werden oder der Wert einer Schlüsselspalte geändert wird, wodurch diese auf einen anderen Indexknoten verschoben wird? Dies führt dazu, dass der Index möglicherweise eine Neuorganisation benötigt, die sich auf alle zugehörigen Indizes und Vorgänge auswirkt , was zu einem weit verbreiteten Rückgang der Produktivität führte.
Ähnliche Vorgänge laufen beim Anruf eines Operators ab LÖSCHEN. Ein Index kann dabei helfen, die zu löschenden Daten zu finden, aber das Löschen der Daten selbst kann zu einer Neuordnung der Seite führen. Bezüglich des Betreibers EINFÜGEN, der Hauptfeind aller Indizes: Sie beginnen, eine große Datenmenge hinzuzufügen, was zu Änderungen in den Indizes und deren Neuorganisation führt und alle darunter leiden.
Berücksichtigen Sie daher die Arten von Abfragen an Ihre Datenbank, wenn Sie darüber nachdenken, welche Art von Indizes und wie viele Sie erstellen möchten. Mehr bedeutet nicht besser. Berücksichtigen Sie vor dem Hinzufügen eines neuen Index zu einer Tabelle nicht nur die Kosten für die zugrunde liegenden Abfragen, sondern auch den verbrauchten Speicherplatz sowie die Kosten für die Aufrechterhaltung von Funktionen und Indizes, was zu einem Dominoeffekt auf andere Vorgänge führen kann. Ihre Indexentwurfsstrategie ist einer der wichtigsten Aspekte Ihrer Implementierung und sollte viele Überlegungen umfassen, von der Größe des Index über die Anzahl der eindeutigen Werte bis hin zur Art der Abfragen, die der Index unterstützt.

Ist es notwendig, einen Clustered-Index für eine Spalte mit einem Primärschlüssel zu erstellen?

Sie können einen Clustered-Index für jede Spalte erstellen, die die erforderlichen Bedingungen erfüllt. Es ist wahr, dass ein Clustered-Index und eine Primärschlüsseleinschränkung füreinander geschaffen sind und eine himmlische Übereinstimmung darstellen. Verstehen Sie also, dass beim Erstellen eines Primärschlüssels automatisch ein Clustered-Index erstellt wird, wenn noch keiner vorhanden ist zuvor erstellt. Sie können jedoch entscheiden, dass ein Clustered-Index anderswo eine bessere Leistung erbringen würde, und oft wird Ihre Entscheidung gerechtfertigt sein.
Der Hauptzweck eines Clustered-Index besteht darin, alle Zeilen in Ihrer Tabelle basierend auf der Schlüsselspalte zu sortieren, die beim Definieren des Index angegeben wurde. Dies ermöglicht eine schnelle Suche und einen einfachen Zugriff auf Tabellendaten.
Der Primärschlüssel einer Tabelle kann eine gute Wahl sein, da er jede Zeile in Tabellen eindeutig identifiziert, ohne dass zusätzliche Daten hinzugefügt werden müssen. In einigen Fällen ist ein Ersatz-Primärschlüssel die beste Wahl, der nicht nur eindeutig, sondern auch klein ist und dessen Werte sequentiell ansteigen, wodurch nicht gruppierte Indizes, die auf diesem Wert basieren, effizienter werden. Auch dem Abfrageoptimierer gefällt diese Kombination aus einem Clustered-Index und einem Primärschlüssel, da das Zusammenführen von Tabellen schneller ist als das Zusammenführen auf andere Weise, bei der kein Primärschlüssel und der zugehörige Clustered-Index verwendet werden. Wie ich schon sagte, es ist eine himmlische Verbindung.
Abschließend ist jedoch zu beachten, dass bei der Erstellung eines Clustered-Index mehrere Aspekte zu berücksichtigen sind: Wie viele Nicht-Cluster-Indizes werden darauf basieren, wie oft ändert sich der Wert der Schlüsselindexspalte und wie groß. Wenn sich die Werte in den Spalten eines Clustered-Index ändern oder der Index nicht wie erwartet funktioniert, können alle anderen Indizes in der Tabelle betroffen sein. Ein Clustered-Index sollte auf der beständigsten Spalte basieren, deren Werte in einer bestimmten Reihenfolge zunehmen, sich aber nicht zufällig ändern. Der Index muss Abfragen für die Daten der Tabelle unterstützen, auf die am häufigsten zugegriffen wird, damit die Abfragen die Tatsache voll ausnutzen, dass die Daten an den Stammknoten, den Blättern des Index, sortiert und zugänglich sind. Wenn der Primärschlüssel zu diesem Szenario passt, verwenden Sie ihn. Wenn nicht, wählen Sie einen anderen Spaltensatz.

Was passiert, wenn Sie eine Ansicht indizieren, ist es dann immer noch eine Ansicht?

Eine Ansicht ist eine virtuelle Tabelle, die Daten aus einer oder mehreren Tabellen generiert. Im Wesentlichen handelt es sich um eine benannte Abfrage, die Daten aus den zugrunde liegenden Tabellen abruft, wenn Sie diese Ansicht abfragen. Sie können die Abfrageleistung verbessern, indem Sie in dieser Ansicht einen gruppierten Index und nicht gruppierte Indizes erstellen, ähnlich wie Sie Indizes für eine Tabelle erstellen. Der größte Nachteil besteht jedoch darin, dass Sie zuerst einen gruppierten Index erstellen und dann einen nicht gruppierten Index erstellen können.
Wenn eine indizierte Ansicht (materialisierte Ansicht) erstellt wird, bleibt die Ansichtsdefinition selbst eine separate Einheit. Dies ist schließlich nur ein fest codierter Operator WÄHLEN, in der Datenbank gespeichert. Aber der Index ist eine ganz andere Geschichte. Wenn Sie einen Clustered- oder Nonclustered-Index für einen Anbieter erstellen, werden die Daten wie bei einem regulären Index physisch auf der Festplatte gespeichert. Wenn sich Daten in zugrunde liegenden Tabellen ändern, ändert sich außerdem automatisch der Index der Ansicht (das bedeutet, dass Sie die Indizierung von Ansichten für Tabellen, die sich häufig ändern, möglicherweise vermeiden sollten). In jedem Fall bleibt die Ansicht eine Ansicht – eine Ansicht der Tabellen, die jedoch im Moment ausgeführt wird, mit entsprechenden Indizes.
Bevor Sie einen Index für eine Ansicht erstellen können, muss diese mehrere Einschränkungen erfüllen. Beispielsweise kann eine Ansicht nur auf Basistabellen verweisen, nicht jedoch auf andere Ansichten, und diese Tabellen müssen sich in derselben Datenbank befinden. Es gibt tatsächlich noch viele andere Einschränkungen, also schauen Sie unbedingt in der Dokumentation nach SQL Server für all die schmutzigen Details.

Warum einen abdeckenden Index anstelle eines zusammengesetzten Index verwenden?

Stellen wir zunächst sicher, dass wir den Unterschied zwischen den beiden verstehen. Ein zusammengesetzter Index ist einfach ein regulärer Index, der mehr als eine Spalte enthält. Es können mehrere Schlüsselspalten verwendet werden, um sicherzustellen, dass jede Zeile in einer Tabelle eindeutig ist. Möglicherweise verfügen Sie auch über mehrere Spalten, um sicherzustellen, dass der Primärschlüssel eindeutig ist, oder Sie versuchen möglicherweise, die Ausführung häufig aufgerufener Abfragen für mehrere Spalten zu optimieren. Im Allgemeinen gilt jedoch: Je mehr Schlüsselspalten ein Index enthält, desto weniger effizient ist der Index, was bedeutet, dass zusammengesetzte Indizes mit Bedacht eingesetzt werden sollten.
Wie bereits erwähnt, kann eine Abfrage von großem Nutzen sein, wenn sich alle erforderlichen Daten genau wie der Index selbst sofort auf den Blättern des Index befinden. Dies ist für einen Clustered-Index kein Problem, da Alle Daten sind bereits vorhanden (weshalb es so wichtig ist, bei der Erstellung eines Clustered-Index sorgfältig darüber nachzudenken). Ein nicht gruppierter Index für Blätter enthält jedoch nur Schlüsselspalten. Um auf alle anderen Daten zuzugreifen, erfordert der Abfrageoptimierer zusätzliche Schritte, die einen erheblichen Mehraufwand bei der Ausführung Ihrer Abfragen verursachen können.
Hier hilft der Deckungsindex. Wenn Sie einen nicht gruppierten Index definieren, können Sie zusätzliche Spalten zu Ihren Schlüsselspalten angeben. Angenommen, Ihre Anwendung fragt häufig Spaltendaten ab Auftragsnummer Und Auftragsdatum in der Tabelle Verkäufe:
SELECT OrderID, OrderDate FROM Sales WHERE OrderID = 12345;
Sie können für beide Spalten einen zusammengesetzten, nicht gruppierten Index erstellen, aber die OrderDate-Spalte erhöht nur den Aufwand für die Indexpflege, ohne als besonders nützliche Schlüsselspalte zu dienen. Die beste Lösung wäre, einen abdeckenden Index für die Schlüsselspalte zu erstellen Auftragsnummer und zusätzlich enthaltene Spalte Auftragsdatum:
CREATE NONCLUSTERED INDEX ix_orderid ON dbo.Sales(OrderID) INCLUDE (OrderDate);
Dadurch werden die Nachteile der Indizierung redundanter Spalten vermieden und gleichzeitig die Vorteile der Speicherung von Daten in Blättern beim Ausführen von Abfragen beibehalten. Die enthaltene Spalte ist nicht Teil des Schlüssels, aber die Daten werden auf dem Blattknoten, dem Indexblatt, gespeichert. Dadurch kann die Abfrageleistung ohne zusätzlichen Aufwand verbessert werden. Darüber hinaus unterliegen die im abdeckenden Index enthaltenen Spalten weniger Einschränkungen als die Schlüsselspalten des Index.

Spielt die Anzahl der Duplikate in einer Schlüsselspalte eine Rolle?

Wenn Sie einen Index erstellen, müssen Sie versuchen, die Anzahl der Duplikate in Ihren Schlüsselspalten zu reduzieren. Oder genauer: Versuchen Sie, die Wiederholungsrate so gering wie möglich zu halten.
Wenn Sie mit einem zusammengesetzten Index arbeiten, gilt die Duplizierung für alle Schlüsselspalten als Ganzes. Eine einzelne Spalte kann viele doppelte Werte enthalten, es sollte jedoch nur minimale Wiederholungen in allen Indexspalten geben. Sie erstellen beispielsweise einen zusammengesetzten nicht gruppierten Index für Spalten Vorname Und Familienname, Nachname Sie können viele John Doe-Werte und viele Doe-Werte haben, aber Sie möchten so wenige John Doe-Werte wie möglich haben oder vorzugsweise nur einen John Doe-Wert.
Das Eindeutigkeitsverhältnis der Werte einer Schlüsselspalte wird als Indexselektivität bezeichnet. Je mehr eindeutige Werte vorhanden sind, desto höher ist die Selektivität: Ein eindeutiger Index weist die größtmögliche Selektivität auf. Die Abfrage-Engine mag Spalten mit hohen Selektivitätswerten sehr, insbesondere wenn diese Spalten in den WHERE-Klauseln Ihrer am häufigsten ausgeführten Abfragen enthalten sind. Je selektiver der Index ist, desto schneller kann die Abfrage-Engine die Größe des resultierenden Datensatzes reduzieren. Der Nachteil besteht natürlich darin, dass Spalten mit relativ wenigen eindeutigen Werten selten gute Kandidaten für die Indizierung sind.

Ist es möglich, einen nicht gruppierten Index nur für eine bestimmte Teilmenge der Daten einer Schlüsselspalte zu erstellen?

Standardmäßig enthält ein nicht gruppierter Index eine Zeile für jede Zeile in der Tabelle. Das Gleiche gilt natürlich auch für einen Clustered-Index, vorausgesetzt, dass es sich bei einem solchen Index um eine Tabelle handelt. Aber wenn es um einen nicht gruppierten Index geht, ist die Eins-zu-Eins-Beziehung ein wichtiges Konzept, denn beginnend mit der Version SQL Server 2008 haben Sie die Möglichkeit, einen filterbaren Index zu erstellen, der die darin enthaltenen Zeilen einschränkt. Ein gefilterter Index kann die Abfrageleistung verbessern, weil... Es ist kleiner und enthält gefilterte, genauere Statistiken als alle tabellarischen Statistiken – dies führt zur Erstellung verbesserter Ausführungspläne. Ein gefilterter Index erfordert außerdem weniger Speicherplatz und geringere Wartungskosten. Der Index wird nur aktualisiert, wenn sich die Daten ändern, die dem Filter entsprechen.
Darüber hinaus lässt sich ganz einfach ein filterbarer Index erstellen. Im Betreiber INDEX ERSTELLEN Sie müssen nur angeben, in WO Filterzustand. Sie können beispielsweise alle Zeilen, die NULL enthalten, aus dem Index herausfiltern, wie im Code gezeigt:
CREATE NONCLUSTERED INDEX ix_trackingnumber ON Sales.SalesOrderDetail(CarrierTrackingNumber) WHERE CarrierTrackingNumber IS NOT NULL;
Tatsächlich können wir alle Daten herausfiltern, die bei kritischen Abfragen nicht wichtig sind. Aber seien Sie vorsichtig, denn... SQL Server erlegt filterbaren Indizes verschiedene Einschränkungen auf, z. B. die Unmöglichkeit, einen filterbaren Index für eine Ansicht zu erstellen. Lesen Sie daher die Dokumentation sorgfältig durch.
Es kann auch sein, dass Sie ähnliche Ergebnisse erzielen können, indem Sie eine indizierte Ansicht erstellen. Ein gefilterter Index bietet jedoch mehrere Vorteile, beispielsweise die Möglichkeit, die Wartungskosten zu senken und die Qualität Ihrer Ausführungspläne zu verbessern. Gefilterte Indizes können auch online neu erstellt werden. Versuchen Sie dies mit einer indizierten Ansicht.

Und noch einmal ein wenig vom Übersetzer

Der Zweck des Erscheinens dieser Übersetzung auf den Seiten von Habrahabr bestand darin, Sie über den SimpleTalk-Blog von zu informieren oder daran zu erinnern RedGate.
Es veröffentlicht viele unterhaltsame und interessante Beiträge.
Ich bin mit keinerlei Unternehmensprodukten verbunden RedGate, noch mit ihrem Verkauf.

Wie versprochen Bücher für alle, die mehr wissen wollen
Ich empfehle drei sehr gute Bücher von mir (Links führen zu entzünden Versionen im Shop Amazonas):

Grundsätzlich können Sie einfache Indizes öffnen

für Anfänger

Index

Tags hinzufügen

Microsoft SQL Server 2012 T-SQL-Grundlagen (Referenz für Entwickler) Autor Itzik Ben-Gan Veröffentlichungsdatum: 15. Juli 2012 Der Autor, ein Meister seines Fachs, vermittelt grundlegende Kenntnisse im Umgang mit Datenbanken. Wenn Sie alles vergessen haben oder es nie wussten, ist es auf jeden Fall eine Lektüre wert.

ROWID-Indizes sind Datenbankobjekte, die eine Anzeige aller Werte in einer Tabellenspalte sowie der ROWIDs aller Zeilen in der Tabelle bereitstellen, die die Werte der Spalte enthalten.

REIHE ist eine Pseudospalte, die eine eindeutige Kennung für eine Zeile in einer Tabelle darstellt und tatsächlich den genauen physischen Speicherort dieser bestimmten Zeile beschreibt. Basierend auf diesen Informationen Orakel kann anschließend die mit der Tabellenzeile verknüpften Daten finden. Jedes Mal, wenn eine Zeile verschoben, exportiert, importiert oder ein anderer Vorgang durchgeführt wird, der ihre Position ändert, wird die REIHE Linie, weil sie eine andere physikalische Position einnimmt. Zur Datenspeicherung REIHE 80 Bit (10 Byte) erforderlich. Identifikatoren REIHE bestehen aus vier Komponenten: Objektnummer (32 Bit), relative Dateinummer (10 Bit), Blocknummer (22 Bit) und Zeilennummer (16 Bit). Diese Kennungen werden als 18-stellige Sequenzen angezeigt, die den Speicherort der Daten in der Datenbank angeben, wobei jedes Zeichen im Base-64-Format dargestellt wird und aus den Zeichen A-Z, a-z, 0-9, + und / besteht. Die ersten sechs Zeichen sind die Datenobjektnummer, die nächsten drei sind die relative Dateinummer, die nächsten sechs sind die Blocknummer und die letzten drei sind die Zeilennummer.

Beispiel:

Familie auswählen, REIHE VON Schüler;

FAM REIHE

——————————————

IVANOV AAAA3kAAGAAAAGsAAA

PETROV AAAA3kAAGAAAAGsAAB

In der Datenbank Orakel Indizes werden für verschiedene Zwecke verwendet: um die Eindeutigkeit von Werten in der Datenbank sicherzustellen, um die Leistung bei der Suche nach Datensätzen in einer Tabelle zu verbessern usw. Die Leistung wird verbessert, indem ein Verweis auf die indizierte Spalte oder Spalten in die Suchkriterien aufgenommen wird für Daten in der Tabelle. IN Orakel Indizes können für jede Tabellenspalte mit Ausnahme von LONG-Spalten erstellt werden. Indizes unterscheiden zwischen geschwindigkeitsunabhängigen Anwendungen und Hochleistungsanwendungen, insbesondere bei der Arbeit mit großen Tabellen. Bevor Sie sich jedoch für die Erstellung eines Index entscheiden, müssen Sie die Vor- und Nachteile hinsichtlich der Systemleistung abwägen. Die Leistung verbessert sich nicht, wenn Sie einfach einen Index eingeben und ihn vergessen.

Obwohl die größte Leistungsverbesserung durch die Erstellung eines Indexes für eine Spalte erzielt wird, in der alle Werte eindeutig sind, können Sie ähnliche Ergebnisse für Spalten erhalten, die doppelte oder NULL-Werte enthalten. Für die Erstellung eines Index ist es nicht erforderlich, dass die Spaltenwerte eindeutig sind. Hier sind einige Empfehlungen, die Ihnen dabei helfen sollen, die gewünschte Leistungssteigerung bei der Verwendung eines Standardindexes zu erreichen. Außerdem gehen wir auf Probleme im Zusammenhang mit dem Gleichgewicht zwischen Leistung und Speicherplatzverbrauch beim Erstellen eines Indexes ein.

Die Verwendung von Indizes zum Nachschlagen von Informationen in Tabellen kann zu erheblichen Leistungsverbesserungen gegenüber dem Scannen von Tabellen führen, deren Spalten nicht indiziert sind. Allerdings ist die Auswahl des richtigen Index gar nicht so einfach. Natürlich ist eine Spalte, deren Werte alle eindeutig sind, für die Indizierung mit einem B-Tree-Index vorzuziehen, aber eine Spalte, die diese Anforderungen nicht erfüllt, ist ein guter Kandidat, solange etwa 10 % ihrer Zeilen identische Werte enthalten und nicht mehr. „Switch“- oder „Flag“-Spalten, beispielsweise solche, die Informationen über das Geschlecht einer Person speichern, sind für B-Tree-Indizes nicht geeignet. Spalten, die zum Speichern einer kleinen Anzahl „zuverlässiger Werte“ verwendet werden, sowie solche, die speichern Bestimmte Werte sind ebenfalls nicht geeignet. Dann sind Zeichen beispielsweise „Zuverlässigkeit“ oder „Unzuverlässigkeit“, „Aktivität“ oder „Inaktivität“, „Ja“ oder „Nein“ usw. usw. Schließlich sind es Indizes mit umgekehrten Schlüsseln In der Regel dort eingesetzt, wo es installiert und betrieben wird Orakel Parallel Server und Sie müssen den Grad der Parallelität in der Datenbank auf das Maximum erhöhen.