非集群索引表上的性能问题

我们有一张约有100,000条记录的表，这个记录在我们的应用程序中经常使用。我们有一个身份（ID）列，并有一个聚集索引，并且一切运作良好。但由于某些原因，我们不得不使用Uniqueidentifier列作为主键。因此，我们在其上添加一个非聚集索引并删除ID列上的聚集索引。但是现在，我们在高峰时期有很多客户的性能下降问题。是否因为表格现在没有聚集索引？非集群索引表上的性能问题

来源

2012-07-12 user1023137

它取决于您用来访问数据的查询。为什么不把UniqueIdentifier作为主键？ – PraveenVenu 2012-07-12 06:07:34

Guid列现在是主键，它具有非聚簇索引 – user1023137 2012-07-12 06:11:30

您是否明确地将其设为非聚簇？ PK默认为聚簇索引。 – PraveenVenu 2012-07-12 06:15:15

您添加主键的事实决不意味着您必须删除聚集索引。这两个概念是不同的。您可以使用由非聚集索引和单独的聚集索引（例如旧的ID列）实现的uniqueidentifier PK。

但真正的问题是当您添加唯一标识符PK时，您是如何更改应用程序的？您是否还修改了应用程序代码以通过此新PK（通过uniqueidentifier）检索记录？你是否更新所有连接来引用新的PK？您是否修改了引用旧ID列的所有外键约束条件？或者应用程序是否继续使用旧标识ID列检索数据？我的期望是，您更改了这两个应用程序和表，并且访问现在流行的形式为SELECT ... FROM table WHERE [email protected]。如果只有发生此类访问，那么即使使用非群集uniqueidentifier主键并且没有聚簇索引，该表也应该执行OK。所以必须有别的东西在起作用：

您的应用程序将继续按照旧标识ID列
有你的查询连接基于旧的身份ID列
有访问表引用旧的ID列上的表的外键约束

最终，您将遇到性能问题疑难解答问题，并将其视为性能问题排查问题。我有两个很好的资源给你： Waits and Queue methodology和Performance Troubleshooting Flowchart

来源

2012-07-12 06:37:55

是的，我们修改了我们的应用程序并写了千行的脚本（！）来更新所有其他表和关系，我们没有放弃ID列，但放弃了聚集索引，它在系统正常情况下正常工作，但在高峰时间，它是真正的很慢。非常感谢你提供有用的链接。我将阅读它们，并再次询问问题是否会延长:) – user1023137 2012-07-12 08:40:14

嗨我认为你可以使用NEWSEQUENTIALID（）而不是NEWID（）将uniqueidentifier列作为聚簇索引。随着newsequentialid生成序列ID和聚簇索引，它是最好的。

来源

2012-07-12 09:06:57 AnandPhadke

非集群索引表上的性能问题

回答

相关问题