由于使用GUID（uniqueidentifier）而导致的数据库修改

Question

我已经完成的应用程序已经上线，并且就特定表格中的响应时间而言，我们正面临一些非常具体的问题。

简而言之，某些具有5k行的表的响应时间非常短。而这些表格的规模会越来越大。

这些表中的一些（例如Order Header表）具有与P.K.相同的唯一标识符。我们认为这可能是响应时间较短的原因。

在研究的情况下，我们已经决定下列选项

1. 转换表中OrderHeader主键索引到一个非聚集之一。
2. 使用NEWSEQUENTIALID（）作为PK，而不是NEWID（默认值）
3. 转换的PK为一个BIGINT

我们认为，选择2号是理想的，因为选择3号需要大票变化。

但要实现我们需要将插入存储过程中的一些处理移动到触发器。这是因为我们需要从OrderHeader表中捕获PK，并且我们无法使用

在插入存储过程中选择@OrderID = newsequentialid（）。

而如果我们继续把处理转移到触发器，我们可以使用

从插入

选择的OrderID现在的问题吗？

1. 将PK从newid（）转换为newsequentialid（）会导致性能增益吗？

2. 会将PK索引转换为非聚簇索引并保留uniqueidentifier作为PK的数据类型和newid（）来生成PK解决我们的问题？

3. 如果你遇到类似的那种情况，请不要让提前人们提供有用的建议

感谢吨

罗米

Answer 1

将表OrderHeader中的主键索引转换为非集群索引。

似乎是一个很好的选择，无论你做什么。如果您的表使用pkey进行聚簇，而后者是UUID，则意味着您不断在表的中间写入某个位置，而不是将新行添加到该表的末尾。仅此一项就会导致性能下降。

建议使用对排序实际有用的索引对表进行聚类;理想情况下日期字段上的东西，不太理想（但仍然非常有用）标题/名称等。

Answer 2

移动聚集索引断开GUID列，到其他某些列的组合（例如，您最常运行的范围搜索）

请张贴您的表格结构和索引定义以及问题查询

在您做出任何更改之前：您需要测量并确定实际瓶颈的位置。

GUID主键的一个常见原因是在客户端层生成这些ID，但是您不提这一点。

此外，您的统计信息是否最新？你是否定期重建索引？