我们有一个大约有100000条记录的表，它在我们的应用程序中经常使用。我们有一个标识（ID）列，上面有一个聚集索引，一切都很好。但由于某些原因，我们不得不使用Uniqueidentifier列作为主键。因此，我们在上面添加了一个非聚集索引，并删除了ID列上的聚集索引。但现在，我们的客户在高峰时段提出了许多性能降级问题。是因为表现在没有聚集索引吗？
添加主键并不意味着必须删除聚集索引。这两个概念是不同的。您可以通过非聚集索引和单独选择的聚集索引（例如，旧的ID列）来实现uniqueidentifier PK。
但真正的问题是当您添加uniqueidentifier PK时，您是如何更改应用程序的？您是否也修改了应用程序代码以通过此新PK（通过uniqueidentifier）检索记录？您是否更新了所有加入以引用新PK？您是否修改了所有引用旧ID列的外键约束？还是应用程序继续使用旧标识ID列检索数据？我的期望是，您同时更改了应用程序和表，并且访问现在以SELECT ... FROM table WHERE pk=@uniqueidentifier的形式流行。如果只发生这样的访问，则即使使用非聚集的uniqueidentifier主键且没有聚集索引，表也应执行正常操作。因此，肯定还有其他因素在起作用：
- 应用程序继续基于旧标识
ID列访问表 - 查询中存在基于旧标识
ID列的联接 - 存在引用旧
ID列上的表的外键约束
最终，您手头有一个性能故障排除问题，并将其作为性能故障排除的问题来处理。我有两个很好的资源可供您使用：Waits and Queue方法论和性能故障排除流程图
Hi我认为您可以使用NEWSEQUENTIALID（）而不是NEWID（）将uniqueidentifier列作为聚集索引。由于newsequentialid生成顺序id，因此对于聚集索引来说是最好的。