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

Question

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

简而言之，在一些有5k行的表中，响应时间非常短。这些桌子的尺寸会越来越大。

其中一些表（例如Order Header表）具有唯一标识符作为p.K.。我们认为这可能是响应时间较低的原因。

在研究情况后，我们决定了以下选项

1. 将表OrderHeader中主键的索引转换为非聚集索引
2. 使用newsequentialid（）作为PK的默认值，而不是newid（）
3. 将PK转换为bigint

我们认为第2个选项是理想的，因为第3个选项需要大幅度的更改。

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

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

然而，如果我们将处理转移到触发器，我们可以使用

从插入的中选择订单ID

现在开始提问？

1. 将PK从newid（）转换为newsequentialid（）会带来性能提升吗？

2. 将PK的索引转换为非聚集索引，并保留uniqueidentifier作为PK的数据类型和用于生成PK的newid（）是否可以解决我们的问题？

3. 如果你面临类似的情况，请提供有用的建议

感谢提前吨人

Romi

Answer 1

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

无论你做什么，这似乎都是一个很好的选择。如果你的表是使用你的pkey集群的，而后者是一个UUID，这意味着你一直在表的中间写东西，而不是在表的结尾附加新行。这一点就会导致性能打击。

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

Answer 2

将聚集索引从GUID列移到其他列的组合上（例如，您最常运行的范围搜索）

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

在进行任何更改之前：您需要测量并确定实际瓶颈在哪里。

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

另外，你的统计数据是最新的吗？是否定期重建索引？