由于使用GUID(唯一标识符)而在数据库中进行了修改

|| 我已经完成的应用程序已经上线了,就特定表中的响应时间而言,我们面临着一些非常具体的问题。 简而言之,在某些具有5k行的表中,响应时间非常短。这些表的大小将不断增加。 这些表中的一些(例如订单标题表)具有唯一标识符作为P.K.我们认为这可能是响应时间短的原因。 在研究情况时,我们决定了以下选择 将表OrderHeader中的主键的索引转换为非聚集键。 使用newsequentialid()作为PK的默认值,而不是newid() 将PK转换为bigint 我们认为2号选件是理想的选择,因为3号选件需要进行较大的更改。 但是要实现这一点,我们需要将插入存储过程中的某些处理移至触发器。这是因为我们需要从OrderHeader表中捕获PK,并且无法使用 在插入存储过程中选择@OrderID = newsequentialid()。 而如果我们将处理移至触发器,则可以使用 从插入中选择OrderID 现在有问题吗? 将PK从newid()转换为newsequentialid()会提高性能吗? 将PK的索引转换为非聚集索引并保留uniqueidentifier作为PK的数据类型和newid()来生成PK是否可以解决我们的问题? 如果您遇到类似情况,请提供有用的建议 提前感谢一吨人 罗米     
已邀请:
  将表OrderHeader中的主键的索引转换为非聚集键。 无论您做什么,似乎都是一个不错的选择。如果您的表是使用pkey集群的,而pkey是UUID,则意味着您经常在表的中间位置进行写操作,而不是在表末尾添加新行。仅此一项将导致性能下降。 最好使用实际上对排序有用的索引来聚簇表;理想情况下,日期字段中的内容,不太理想(但仍然非常有用)的标题/名称等。     
将聚集索引从GUID列移到其他列组合(例如,您最常运行的范围搜索) 请发布您的表结构和索引定义以及问题查询 进行任何更改之前:您需要测量并确定实际瓶颈在哪里。 GUID主键的常见原因之一是在客户端层中生成这些ID,但是您不会在此提及。 另外,您的统计信息是否最新?您是否定期重建索引?     

要回复问题请先登录注册