Ich habe eine Tabelle wie folgt:
%Vor%keyA und keyB zusammen sind eindeutig, sind der Primärschlüssel meiner Tabelle und bilden einen Clustered-Index.
Es gibt 5 mögliche Werte für keyB, aber eine unbegrenzte Anzahl von möglichen Werten für keyA ,. keyB wird normalerweise inkrementiert.
Beispielsweise können die folgenden Daten auf zwei Arten sortiert werden, je nachdem, welche Schlüsselspalte zuerst bestellt wird:
%Vor%oder
%Vor%Muss ich dem Clustered-Index mitteilen, welche der Schlüsselspalten weniger mögliche Werte hat, damit er die Daten zuerst nach diesem Wert sortieren kann? Oder spielt es für die Leistung keine Rolle, wer zuerst bestellt wird?
Sie sollten Ihren zusammengesetzten gruppierten Index zuerst mit der selektivsten Spalte bestellen. Dies bedeutet die Spalte mit den deutlichsten Werten im Vergleich zur Gesamtzahl der Zeilen.
"B * TREE-Indizes verbessern die Leistung von Abfragen, die einen kleinen Prozentsatz von Zeilen aus einer Tabelle auswählen." Ссылка ?
Dieser Artikel ist für Oracle, aber immer noch relevant.
Wenn Sie eine Abfrage haben, die ständig ausgeführt wird und nur wenige Felder zurückgibt, können Sie einen zusammengesetzten Index erstellen, der alle Felder enthält. Er muss nicht auf die Basistabelle zugreifen, sondern stattdessen Daten aus dem Index abrufen.
Der Kommentar vonligget78, der darauf achtet, die erste Spalte in einem zusammengesetzten Index zu erwähnen, ist wichtig, um sich daran zu erinnern.
Wenn Sie einen Index (unabhängig von Cluster oder nicht) mit (keyA, keyB) erstellen, werden die Werte so geordnet, z. zuerst keyA, dann keyB (dies ist der zweite Fall in Ihrer Frage). Wenn Sie es andersherum möchten, müssen Sie angeben (keyB, keyA).
Es könnte leistungsbezogen sein, hängt natürlich von Ihrer Anfrage ab. Wenn Sie beispielsweise den Schlüssel (keyA, keyB) haben und die Abfrage wie WHERE keyB = ... aussieht (ohne keyA zu erwähnen), kann der Index nicht verwendet werden.
Wie andere bereits gesagt haben, hängt die Reihenfolge davon ab, wie Sie es im Indexerstellungsskript (oder PK-Einschränkung) angeben. Eine Sache über Clustered-Indizes ist jedoch, dass es eine Menge zu beachten gibt.
Sie können eine bessere Gesamtleistung erzielen, wenn Sie Ihren Clustered-Index für etwas anderes als das PK verwenden. Wenn Sie beispielsweise ein Finanzsystem schreiben und Berichte fast immer auf dem Datum und der Uhrzeit einer Aktivität basieren (alle Aktivitäten für das vergangene Jahr usw.), ist möglicherweise ein gruppierter Index für diese Datumsspalte besser. Wie HLGEM sagt, kann die Sortierung auch von der Auswahl des gruppierten Indexes beeinflusst werden.
Clustered-Indizes können die Einfügungen auch stärker beeinflussen als andere Indizes. Wenn Sie ein hohes Volumen an Einfügungen haben und Ihr Clustered-Index sich in einer IDENTITY-Spalte befindet, kann es zu Konfliktproblemen für diesen bestimmten Teil der Festplatte kommen, da alle neuen Zeilen an derselben Stelle eingefügt werden.
Bei kleinen Nachschlagetabellen lege ich den Clustered Index immer nur auf den PK. Für Tabellen mit hoher Auswirkung ist es jedoch eine gute Idee, sich die Zeit zu nehmen, verschiedene mögliche Clustered-Indizes zu betrachten (und zu testen), bevor Sie die beste auswählen.
Ich glaube, dass SQL Server es genau so anordnet, wie Sie es sagen. Es setzt voraus, dass Sie am besten wissen, wie Sie auf Ihren Index zugreifen.
Auf jeden Fall würde ich sagen, dass es eine gute Idee ist, wo genau es möglich ist, genau das zu spezifizieren, was Sie wollen, anstatt zu hoffen, dass die Datenbank es herausfinden wird.
Sie können es auch auf beide Arten versuchen, eine Reihe von repräsentativen Abfragen ausführen und dann die generierten Ausführungspläne vergleichen, um festzustellen, welche für Sie am besten ist.
Nur für den Fall, dass dies nicht offensichtlich ist: Die Sortierreihenfolge Ihres Index verspricht nicht viel über die Sortierreihenfolge der Ergebnisse in einer Abfrage .
In Ihren Abfragen müssen Sie immer noch ein
hinzufügen %Vor%oder
%Vor%Der Optimierer kann erfreut sein, die Daten, die bereits physisch im Index geordnet sind, wie gewünscht zu finden und etwas Zeit zu sparen, aber jede Abfrage, die Daten in einer bestimmten Reihenfolge liefern soll, muss eine ORDER BY-Klausel am Ende haben. Ohne eine Reihenfolge von, macht SQL Server keine Versprechen in Bezug auf die Reihenfolge eines Recordsets, oder sogar, dass es in der gleichen Reihenfolge von Abfrage zu Abfrage zurückkommt.
Am besten testen Sie beide Lösungen und messen Sie die Ausführungszeit.
Nach meiner Erfahrung ist Index-Tuning alles andere als genau-Wissenschaft.
Vielleicht wäre keyB vor keyA in der Reihenfolge der Indexspalten besser
Sie geben die Spalten in der Reihenfolge an, in der sie normalerweise in Berichten und Abfragen sortiert werden sollen.
Ich würde jedoch vorsichtig sein, einen mehrspaltigen Clustered-Index zu erstellen. Je nachdem, wie groß dieser Wert ist, können Sie einen großen Einfluss auf die Größe anderer Indizes haben, die Sie erstellen, da alle nicht gruppierten Indizes den darin enthaltenen Clustered-Index-Wert enthalten. Außerdem müssen die Zeilen neu geordnet werden, wenn sich die Werte häufig ändern, und es ist die Erfahrung, dass Schlüssel, die keine Ersatzschlüssel sind, sich häufiger ändern. Daher kann das Erstellen eines Clustered-Vice-Nonclustered-Indexes viel zeitaufwändiger für Serverressourcen sein, wenn Sie Werte haben, die sich wahrscheinlich ändern. Ich sage nicht, dass Sie das nicht tun sollten, da ich nicht weiß, welche Art von Daten Ihre Spalten tatsächlich enthalten (obwohl ich vermute, dass sie komplexer sind als A1, A2 usw.); Ich sage, dass Sie über die Konsequenzen davon nachdenken müssen. Es wäre wahrscheinlich eine gute Idee, BOL gründlich über Clustered Vice Nonclustered-Indizes zu lesen, bevor Sie sich dazu verpflichten.
Denken Sie daran, dass der gruppierte Index die physische Reihenfolge ist, in der die Tabelle auf der Festplatte gespeichert ist.
Wenn Ihr Clustered-Index als ColA definiert ist, werden ColB-Abfragen schneller ausgeführt, wenn die Reihenfolge in der Reihenfolge Ihres Clustered-Indexes liegt. Wenn SQL B, A bestellen muss, muss nach der Ausführung sortiert werden, um die richtige Reihenfolge zu erreichen.
Mein Vorschlag ist, einen zweiten nicht gruppierten Index auf B, A hinzuzufügen. Abhängig von der Größe Ihrer Datenspalte ist es auch INCLUDE (lesen Sie die enthaltene Spalte), um Schlüsselabfragen zu vermeiden. Das ist natürlich vorausgesetzt, dass diese Tabelle nicht stark eingefügt wird, da Sie immer die Abfragegeschwindigkeit vs. Schreibgeschwindigkeit balancieren müssen.
Realistisch gesehen sollte Ihr Clustered-Index die Reihenfolge darstellen, in der auf die Daten am wahrscheinlichsten zugegriffen wird, und ein empfindliches Gleichgewicht zwischen Einfüge- und Aktualisierungs-IO-Kosten beibehalten. Wenn Ihr Clustered-Index so aussieht, dass Sie ständig in die Mitte von Seiten einfügen, können Sie dort Leistungseinbußen erleiden.
Wie andere schon gesagt haben, ohne die Tischlänge, Spaltengröße usw. zu kennen, gibt es keine richtige Antwort. Versuch und Irrtum mit einer hohen Dosis von Tests ist Ihre beste Wette.
Ja, Sie sollten vorschlagen, normalerweise Abfrage-Engine versuchen, den besten Ausführungsplan und den Index zu finden, zu nutzen, aber manchmal ist es besser, Abfrage-Engine zu zwingen, den spezifischen Index zu verwenden. Bei der Planung für den Index sowie bei der Verwendung des Indexes in Ihrer Abfrage gibt es weitere Überlegungen. Zum Beispiel die Reihenfolge der Spalten im Index, die Reihenfolge der Spalten in der Where-Klausel. Sie können den folgenden Link verwenden, um Folgendes zu erfahren:
Ich bin mir sicher, dass Ihnen das bei der Planung für den Index helfen wird.
Tags und Links sql sql-server database performance indexing