如果我放弃我的群集PK并添加一个新的，我的行将在什么顺序？

当你删除一个聚簇索引时，这个表就变成了一个堆。 由于堆与索引具有非常不同的物理结构，数据将不得不复制到新的结构中。 堆没有任何秩序。 当您添加新的聚簇索引时，数据将从堆中复制到新索引中，并且顺序将由新聚簇键定义。

如果你想保留现有的命令，那么你所要做的就是正确地分配新的整数ID：

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; 

现在Integer_Ids的顺序将与Guid的顺序相匹配。 您可以删除Guid列，并在新的Integer列上添加聚簇索引，并保留logging的物理顺序。

根据定义，聚集索引对实际数据页面施加物理sorting; 所以，是的，如果你删除聚集索引并创build一个新的，这将强制数据的物理重新sorting。

在你的情况下，我认为可以肯定的是会发生以下情况：

• 现有的聚集索引将被删除，但是磁盘上的实际数据不会因此而移动。
• 您将修改列types（或删除现有的列并创build一个新的列），设置costraints不为空，唯一，主键，身份和自动增量（这是至关重要的，否则SQL Server甚至不会让你添加它，因为它不知道要投入什么）。
• 此时，该列将被SQL Server自动填充。 我不知道这里会发生什么，但是我认为它会按照顺序填充到数据库中。 但我只是猜测这个。
• 问题在于，涉及UID时，sorting可能相当混乱; 所以你不知道数据是如何实际存储的，而且你不知道以后如何存储数据。 如果我关于列人口的猜测是正确的，那么就不会有大的重新sorting……但是可能发生。 即使我是正确的，如果桌子足够大的话，索引build筑无论如何要花费一些时间。

底线：您将会产生巨大的影响，您可以按照您现在得到的顺序从无序的SELECT中获取行。 你将不得不尝试。

根据定义，聚集索引决定了数据的物理顺序，因此当您创build新的聚集索引时，数据将被重新sorting; 如果是一张大桌子，计划花一点时间。

如果使用集群主键创build表，然后删除集群PK，则表中数据的物理顺序将不受干扰。 但是，查询结果的物理顺序不能保证和表中的顺序一样，所以这个顺序是没有意义的。

如果你添加一个整数列并在其上创build一个集群主键，那么这个表将被重新安排到键sorting的顺序中。这可能与GUID的物理顺序相同或不同，具体取决于键的分配方式。 您可以基于GUID键的sorting顺序（例如，使用旧的键sorting中的row_number（））来明确地指定它，或者可以用其他方式指定它。 除非您采取措施确保订单明确相同，否则表中的物理订单或行不能保证您新密钥的订购。