Ich habe eine Reihe von Indizes für einige Tabellen, sie sind alle ähnlich und ich möchte wissen, ob der Clustered Index in der richtigen Spalte ist. Hier sind die Statistiken der beiden aktivsten Indizes:
%Vor%Wie Sie sehen können, wird der PK oft gesucht, aber alle Suchen für die i3_identity-Spalte machen auch Schlüssel-Lookups für diesen PK, also profitiere ich wirklich sehr vom Index auf I3_Identity? Soll ich die I3_Identity als Clustered verwenden? Dies könnte eine große Auswirkung haben, da diese Tabellenstruktur etwa 10000 mal wiederholt wird, wo ich arbeite, so dass jede Hilfe geschätzt wird.
Frederik fasst es gut zusammen, und genau das predigt Kimberly Tripp auch: Der Clustering-Schlüssel sollte stabil sein (niemals ändern), immer größer werden (IDENTITY INT), klein und einzigartig.
In Ihrem Szenario würde ich den Clustering-Schlüssel lieber in die Spalte BIGINT als in die Spalte VARCHAR (80) einfügen.
Zunächst einmal ist es mit der BIGINT-Spalte relativ einfach, die Eindeutigkeit zu erzwingen (wenn Sie die Eindeutigkeit nicht selbst erzwingen und garantieren, fügt SQL Server jeder einzelnen Zeile einen 4-Byte-"uniquefier" hinzu). und es ist im Durchschnitt viel kleiner als ein VARCHAR (80).
Warum ist die Größe so wichtig? Der Clustering-Schlüssel wird auch zu JEDEM und jedem Ihrer nicht gruppierten Indizes hinzugefügt. Wenn Sie also viele Zeilen und viele nicht gruppierte Indizes haben, können Sie mit 40-80 Byte vs. 8 Byte schnell ein RIESIGES Ergebnis erzielen Unterschied.
Auch ein weiterer Leistungstipp: Um die sogenannten Lesezeichen-Lookups zu vermeiden (von einem Wert in Ihrem nicht gruppierten Index über den Clustering-Schlüssel in die eigentlichen Datenblattseiten), hat SQL Server 2005 den Begriff " Spalten in Ihren nicht gruppierten Indizes enthalten. Diese sind extrem hilfreich und werden oft übersehen. Wenn Ihre Abfragen häufig die Indexfelder und nur ein oder zwei andere Felder aus der Datenbank erfordern, sollten Sie diese einbeziehen, um das zu erreichen, was als "Indizes abdecken" bezeichnet wird. Nochmals - siehe Kimberly Tripps ausgezeichneten Artikel - sie ist die SQL Server Indexing Goddess! :-) und sie kann das Zeug viel besser erklären als ich ...
Um es zusammenzufassen: Setzen Sie Ihren Clustering-Schlüssel auf eine kleine, stabile, einzigartige Spalte - und Sie werden es gut machen!
Marc
schnell 'n dreckig:
Setzen Sie den gruppierten Index auf:
eine Spalte, deren Werte sich (fast) nie ändern
eine Spalte, für die Werte für neue Datensätze erhöht / verringert werden sequentiell
eine Spalte, in der Sie die Bereichssuche durchführen
Hier ist die beste Diskussion , die ich gefunden habe das Thema. Kimberly Tripp ist eine MS-Bloggerin, die immer an der Spitze der Debatte steht. Ich könnte es für Sie interpretieren, aber Sie verstehen offensichtlich die grundlegenden Wörter und Konzepte, und der Artikel ist sehr gut lesbar. Also viel Spaß!
Tipp: Sie werden feststellen, dass kurze Antworten fast immer zu einfach sind.
Nach dem, was ich in der Vergangenheit gelesen habe, sind zwei der wichtigsten Kennzahlen in Bezug auf Indextabellen die Anzahl der Abfragen, die für den Index und die Indexdichte durchgeführt werden. Mit DBCC_SHOWSTATISTICS ([Tabelle], [Index]) können Sie die Indexdichte untersuchen. Die Idee ist, dass Sie Ihren Clustered-Index für die Spalten benötigen, die die höchste Unterscheidbarkeit pro Abfrage bieten.
Kurz gesagt, wenn Sie sich das Maß "All density" von DBCC SHOW_STATISTICS anschauen und feststellen, dass die Anzahl sehr niedrig ist, ist dies ein guter Cluster-Index. Es ist logisch sinnvoll, sich auf einen Index zu konzentrieren, der mehr Eindeutigkeit bietet, aber nur, wenn er aktiv abgefragt wird. Clustering auf einem selten genutzten Index wird wahrscheinlich mehr schaden als nützen.
Am Ende ist es ein Urteilsspruch. Vielleicht möchten Sie mit Ihrem Datenbankadministrator sprechen und Ihren Code analysieren, um zu sehen, wo Sie den größten Nutzen erzielen. In diesem eingeschränkten Beispiel scheint Ihre Indizierung im richtigen Bereich geclustert zu sein, wenn Sie nur die Verwendung in Betracht ziehen (und selbst wenn Sie alle Dichte berücksichtigen, da ein Primärschlüssel die größtmögliche Einzigartigkeit bietet.)
Bearbeiten: Es gibt einen ziemlich guten Artikel in MSDN, der erklärt, was SHOW_STATISTICS Ihnen bietet. Ich bin sicherlich kein Uber-DBA, aber die meisten Informationen, die ich hier zur Verfügung gestellt habe, stammen aus der Anleitung unseres DBA:)
Hier ist der Artikel: Ссылка
Wenn ich Schlüsselabfragen für den Schlüssel primär / gruppiert sehe, bedeutet das, dass ich mehr Spalten im nicht gruppierten Schlüssel (mit der Anweisung INCLUDE) einbeziehen muss. Sehen Sie sich Ihre Abfragen an und sehen Sie, welche Spalten in diesen Anweisungen ausgewählt / verwendet werden. Wenn Sie diese Spalten in den nicht gruppierten Schlüssel einschließen, muss die Schlüsselsuche nicht mehr durchgeführt werden.
Tags und Links sql sql-server sql-server-2005 indexing