桌子上的选择速度慢

Angela 发表于 Dev

安吉拉

我正在使用SQL Server，并且有一张这样的表

CREATE TABLE dbo.CompanyRolesExpanded (
  StaticId uniqueidentifier NOT NULL,
  UserId uniqueidentifier NULL,
  UserGroupId uniqueidentifier NULL,
  CompanyId uniqueidentifier NULL,
  CompanyGroupId uniqueidentifier NULL,
  CompanyAccessUnitRole uniqueidentifier NULL,
  PRIMARY KEY CLUSTERED (StaticId)
)
GO

目前，该表大约有300万行。像这样的简单选择大约需要30秒

SELECT  UserId,UserGroupId
       ,CompanyId,CompanyGroupId 
       ,CompanyAccessUnitRole                   
FROM CompanyRolesExpanded

有办法改善吗？

德鲁·乔希

虽然问题的全部内容（例如执行计划，索引）尚不清楚，但我还是想举一个与GUID相关的重大失败清单作为答案。

表中的所有列都有一个GUID。

  StaticId uniqueidentifier NOT NULL,
  UserId uniqueidentifier NULL,
  UserGroupId uniqueidentifier NULL,
  CompanyId uniqueidentifier NULL,
  CompanyGroupId uniqueidentifier NULL,
  CompanyAccessUnitRole uniqueidentifier NULL

从作者偏爱GUID的来源引用负面信息

GUID缺点

它比传统的4字节索引值大4倍；如果您不小心，可能会对性能和存储造成严重影响

在userid ='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'的地方调试很麻烦

生成的GUID应该是部分顺序的，以实现最佳性能（例如，SQL 2005上的newsequentialid（））并允许使用聚簇索引

与使用say int作为Key相比，您的数据将分布在更多页面上，并且将具有更多的物理读取。

如果您执行许多插入/更新/删除操作，则索引将高度分散。之所以这样，是因为GUID是随机生成的，并且要花费大量的时间才能更新索引以按顺序组织它们。

我敢打赌，您的索引需要重建。这是一篇比较GUID和INT列索引的文章，反映出GUID比INT慢，但是可以改进，并且可以与索引重建相提并论。

如果您认为GUID是罪魁祸首，建议您bigint选择

本文收集自互联网，转载请注明来源。

如有侵权，请联系 [email protected] 删除。