Ich habe einige Datenbankerstellungsskripts für eine SQL SERVER 2005-Datenbank geerbt.
Eine Sache, die ich bemerkt habe, ist, dass alle Primärschlüssel als NON CLUSTERED indexes im Gegensatz zu clustered erstellt werden.
Ich weiß, dass Sie nur einen Clustered-Index pro Tabelle haben können und dass Sie ihn in einer Nicht-Primärschlüsselspalte für die Abfrageleistung von Suchen usw. haben möchten. Allerdings gibt es keine weiteren CLUSTERED -Indizes für die Tabellen in Fragen .
Meine Frage ist also, ob es irgendwelche technischen Gründe gibt, Clusterindizes für eine Primärschlüsselspalte außer den oben genannten zu haben.
Auf irgendwelchen "normalen" Daten oder Nachschlagetabellen: Nein, ich sehe überhaupt keinen Grund.
Auf Sachen wie Massenimporttabellen oder temporäre Tabellen - es kommt darauf an.
Für manche Leute scheint es überraschend, dass ein guter Clustered-Index Operationen wie INSERT oder UPDATE beschleunigen kann. Siehe Kimberly Tripps ausgezeichnet Die Debatte über den Clustered Index geht weiter .... Blog Beitrag, in dem sie sehr detailliert erklärt, warum dies der Fall ist.
In diesem Licht: Ich sehe keinen irgendeinen gültigen Grund nicht für einen guten Clustered-Index (eng, stabil, einzigartig, ständig steigend = INT IDENTITY als die offensichtlichste Wahl) für jede SQL Server-Tabelle.
Um zu erfahren, wie und warum Clustering-Schlüssel zu wählen sind, lesen Sie alle hervorragenden Blog-Beiträge von Kimberly Tripp zum Thema:
Ausgezeichnete Sachen von der "Queen of Indexing"! :-)
Clustered-Tabellen und Heap-Tabellen
(Guter Artikel zum Thema auf www.mssqltips.com )
HEAP-Tabelle (ohne gruppierten Index)
Daten werden nicht in einem bestimmten gespeichert Bestellung
Bestimmte Daten können nicht abgerufen werden schnell, es sei denn, es gibt auch Nicht gruppierte Indizes
Datenseiten sind nicht miteinander verknüpft Der sequentielle Zugriff muss zurückverfolgt werden zur Indexzuordnungskarte (IAM) Seiten
Da es keinen gruppierten Index gibt, zusätzliche Zeit wird nicht benötigt Pflegen Sie den Index
Da es keinen gruppierten Index gibt, Es besteht nicht die Notwendigkeit für zusätzliche Speicherplatz zum Speichern des Clustered-Index Baum
Diese Tabellen haben einen index_id-Wert von 0 in der Katalogsicht sys.indexes
Clustered-Tabelle
Die Daten werden in der Reihenfolge gespeichert, die auf den Clustered-Index-Schlüssel
Daten können schnell abgerufen werden auf dem Clustered-Index-Schlüssel, wenn die Abfrage verwendet die indizierten Spalten
Datenseiten sind schneller verknüpft Sequentieller Zugriff Es wird zusätzliche Zeit benötigt, um den Clustered-Index basierend auf zu erhalten INSERTS, UPDATES und DELETES
Zum Speichern wird zusätzlicher Speicherplatz benötigt Clustered-Index-Baum Diese Tabellen haben den Wert index_id von 1 im Katalog sys.indexes Ansicht
Bitte lesen Sie meine Antwort unter " Kein direkter Zugriff auf die Datenzeile in der gruppierten Tabelle - warum?" , zuerst. Speziell Punkt [2] Vorbehalt.
Die Leute, die die "Datenbank" erstellt haben, sind Kretinen. Sie hatten:
Für solche Sammlungen von Tabellen, die als Datenbanken maskiert sind, wird es immer häufiger, CIs ganz zu vermeiden und nur NCIs plus den Heap zu haben. Offensichtlich bekommen sie nichts von der Macht oder den Vorteilen des CI, aber zur Hölle, sie bekommen keine Kraft oder Nutzen von relationalen Datenbanken, also wen interessiert es, dass sie nicht die Macht von CIs bekommen, die für relationale Datenbanken entwickelt wurden ist nicht). So wie sie es sehen, müssen sie sowieso das verflixte Ding "umgestalten", also warum sollten sie sich kümmern. Relationale Datenbanken benötigen kein "Refactoring".
Wenn Sie diese Antwort weiter diskutieren müssen, senden Sie bitte die CREATE TABLE / INDEX DDL; ansonsten ist es ein zeitverschwendendes akademisches Argument.
Hier ist ein weiterer (noch in anderen Antworten vorhandener) möglicher Grund (noch zu verstehen):
Ich hoffe, ich werde später aktualisieren, aber jetzt ist es eher der Wunsch, diese Themen zu verlinken
Update:
Was vermisse ich im Verständnis der gruppierte Index?
Bei einigen heute noch verwendeten b-tree Servern / Programmiersprachen werden flache ascii Dateien mit fester oder variabler Länge zum Speichern von Daten verwendet. Wenn ein neuer Datensatz / Zeile zu einer Datei (Tabelle) hinzugefügt wird, wird der Datensatz (1) an das Ende der Datei angefügt (oder ersetzt einen gelöschten Datensatz) und (2) die Indizes werden ausgeglichen. Wenn Daten auf diese Weise gespeichert werden, müssen Sie sich nicht um die Systemleistung kümmern (soweit der b-tree-Server einen Zeiger auf den ersten Datensatz zurückgibt). Die Antwortzeit wird nur von der Anzahl der Knoten in Ihren Indexdateien beeinflusst.
Wenn Sie sich mit SQL beschäftigen, werden Sie hoffentlich feststellen, dass die Systemleistung beim Schreiben einer SQL-Anweisung berücksichtigt werden muss. Die Verwendung einer "ORDER BY" -Anweisung für eine nicht indizierte Spalte kann ein System in die Knie zwingen. Die Verwendung eines Clustered-Indexes könnte die CPU unnötig belasten. Es ist das 21. Jahrhundert und ich wünschte, wir müssten nicht über die Systemleistung beim Programmieren in SQL nachdenken, aber wir tun es immer noch.
Bei einigen älteren Programmiersprachen war es obligatorisch, einen Index zu verwenden, wenn sortierte Daten abgerufen wurden. Ich wünschte nur, dass diese Anforderung noch heute besteht. Ich kann mich nur wundern, wie viele Unternehmen ihre langsamen Computersysteme wegen einer schlecht geschriebenen SQL-Anweisung auf nicht-indizierten Daten aktualisiert haben.
In meinen 25 Jahren Programmierung habe ich meine physikalischen Daten nie in einer bestimmten Reihenfolge gespeichert. Vielleicht vermeiden deshalb einige Programmierer die Verwendung von Clustered-Indizes. Es ist schwer zu wissen, was der Kompromiss ist (Speicherzeit, Verse-Retrieval-Zeit), besonders wenn das System, das du entwirfst, irgendwann Millionen von Datensätzen speichern könnte.
Tags und Links sql-server sql-server-2005 indexing tsql clustered-index