由于使用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

将聚簇索引从GUID列移到其他一些列组合（例如，最常运行范围搜索）

请发布您的表结构和索引定义以及问题查询

在进行任何更改之前：您需要衡量并确定实际瓶颈的位置。

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

另外，您的统计数据是最新的吗？你经常重建索引吗？

Answer 2

  

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

无论你做什么，似乎都是一个很好的选择。如果您的表是使用您的pkey聚类而后者是UUID，则意味着您经常在表格中间的某处写入，而不是在其末尾添加新行。仅这一点就会导致性能下降。

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