In SQL Server sehe ich mir TableA an, das derzeit einen gruppierten Primärschlüssel mit eindeutigem Bezeichner hat. Die GUID hat in keinem Kontext eine Bedeutung.
(Ich gebe Ihnen eine Sekunde, um Ihre Tastatur und Ihren Monitor aufzuräumen und die Limonade abzustellen.)
Ich möchte diesen Primärschlüssel löschen und der Tabelle einen neuen eindeutigen ganzzahligen Primärschlüssel hinzufügen. Meine Frage ist folgende: Wenn ich den Index lösche, die Spalte von uniqueidentifier in int ändere und den neuen gruppierten eindeutigen Primärschlüssel zur geänderten Spalte hinzufüge, werden die neuen PK-Werte dann in der Reihenfolge angezeigt, in der sie in die Tabelle eingefügt wurden, oder in einer anderen Reihenfolge? Ist das hier der richtige Weg? Wird das funktionieren? (Ich bin so etwas wie ein Neuling, was das Erstellen/Ändern von Tabellen betrifft.)
Antwort1
Wenn Sie einen Clustered-Index löschen, wird die Tabelle zu einem Heap. Da Heaps eine ganz andere physische Struktur als Indizes haben, müssen die Daten in die neue Struktur kopiert werden. Heaps haben keinerlei Ordnung. Wenn Sie einen neuen Clustered-Index wieder hinzufügen, werden die Daten vom Heap in den neuen Index kopiert und die Reihenfolge wird durch den neuen Clustered-Schlüssel definiert.
Wenn Sie die bestehende Reihenfolge beibehalten möchten, müssen Sie lediglich die neuen Integer-IDs richtig zuweisen:
ALTER TABLE Table ADD Integer_Id INT;
GO
WITH cte AS (
SELECT ROW_NUMBER() OVER (ORDER BY Guid_Id) as RowOrderByGuid,
Guid_Id
FROM Table)
UPDATE t
SET t.Integer_Id = c.RowOrderByGuid
FROM Table t
JOIN cte c ON t.Guid_Id = c.Guid_Id;
Jetzt entspricht die Reihenfolge der Integer_Ids der Reihenfolge der Guids. Sie können die Guid-Spalte löschen und einen gruppierten Index für die neue Integer-Spalte hinzufügen. Die physische Reihenfolge der Datensätze bleibt dabei erhalten.
Antwort2
Per Definition erzwingt ein gruppierter Index eine physische Sortierung der tatsächlichen Datenseiten. Wenn Sie also einen gruppierten Index löschen und einen neuen erstellen, wird eine physische Neusortierung der Daten erzwungen.
Ich denke, in Ihrem Fall kann man davon ausgehen, dass Folgendes passieren wird:
- Der vorhandene gruppierte Index wird gelöscht, die eigentlichen Daten auf der Festplatte werden dadurch jedoch nicht verschoben.
- Sie ändern den Spaltentyp (oder löschen die vorhandene Spalte und erstellen eine neue), wobei Sie Einschränkungen festlegen, dass die Spalte ungleich null, eindeutig, ein Primärschlüssel, eine Identität und automatisch inkrementierend sein muss (das ist unbedingt erforderlich, sonst lässt SQL Server Sie die Spalte nicht einmal hinzufügen, weil es nicht weiß, was es einfügen soll).
- An diesem Punkt wird die Spalte automatisch von SQL Server ausgefüllt. Ich weiß nicht genau, was hier passieren wird, aber ichdenkenEs wird in der Reihenfolge ausgefüllt, in der die Zeilen physisch in der Datenbank gespeichert sind. Aber das ist nur eine Vermutung.
- Das Problem besteht darin, dass die Sortierung ziemlich chaotisch sein kann, wenn UIDs im Spiel sind. Sie wissen also weder, wie die Daten jetzt tatsächlich gespeichert sind, noch, wie sie später gespeichert werden. Wenn meine Vermutung bezüglich der Spaltenbelegung richtig ist, wird keine umfassende Neusortierung erforderlich sein, aber es könnte passieren. Und selbst wenn ich richtig liege, wird der Indexaufbau trotzdem eine Weile dauern, wenn die Tabelle groß genug ist.
Fazit: SieWillehaben einen großen Einfluss, und SiekönnteHolen Sie sich Zeilen aus einer ungeordneten SELECT-Anweisung in derselben Reihenfolge, in der Sie sie jetzt erhalten. Sie müssen es versuchen.
Antwort3
Ein gruppierter Index bestimmt per Definition die physische Reihenfolge der Daten. Wenn Sie also den neuen gruppierten Index erstellen, werden die Daten neu geordnet. Wenn es sich um eine große Tabelle handelt, sollten Sie damit rechnen, dass dies eine Weile dauert.
Antwort4
Wenn Sie eine Tabelle mit einem gruppierten Primärschlüssel erstellen und dann den gruppierten Primärschlüssel löschen, bleibt die physische Reihenfolge der Daten in der Tabelle unverändert. Es gibt jedoch keine Garantie dafür, dass die physische Reihenfolge der Abfrageergebnisse mit der Reihenfolge in der Tabelle übereinstimmt. Daher ist diese Reihenfolge ziemlich bedeutungslos.
Wenn Sie dann eine ganzzahlige Spalte hinzufügen und darauf einen gruppierten Primärschlüssel erstellen, wird die Tabelle in die Reihenfolge neu angeordnet, in der der Schlüssel sortiert wird. Dies kann dieselbe physikalische Reihenfolge wie die GUID sein oder auch nicht, je nachdem, wie der Schlüssel zugewiesen wird. Sie können ihn explizit basierend auf der Sortierreihenfolge des GUID-Schlüssels zuweisen (z. B. indem Sie row_number() anstelle der alten Schlüsselreihenfolge verwenden) oder Sie können ihn auf eine andere Weise zuweisen. Sofern Sie nicht Schritte unternehmen, um sicherzustellen, dass die Reihenfolge explizit der physischen Reihenfolge oder den Zeilen in der Tabelle entspricht, ist nicht garantiert, dass die Reihenfolge Ihres neuen Schlüssels bestimmt wird.