Sql Server 旧数据库是否转为聚集索引

Question

我们有一个遗留数据库，它是一个 sql server 数据库(2005 年和 2008 年)。

表中的所有主键都是唯一标识符。

这些表当前没有创建聚集索引，并且我们在只有 750k 记录的表上遇到了性能问题。这是我使用唯一标识符作为唯一主键的第一个数据库，我从未见过 sql server 返回数据这么慢。

我不想在 uniqueidentifier 上创建聚集索引，因为它们不是连续的，因此在插入数据时会减慢应用程序的速度。

我们无法删除 uniqueidentifier，因为它用于远程站点记录身份管理目的。

我曾考虑过向表中添加一个大整数标识列，并在此列上创建聚集索引并包含唯一标识符列。

即

int Identity - 第一列保持插入速度唯一标识符 - 确保应用程序继续按预期工作。

目标是提高身份查询和连接表查询性能。

问题1:这会提高数据库的查询性能还是会降低数据库的查询性能？

问题2:是否有我未列出的替代方案？

谢谢皮特

编辑:性能问题在于通过 select 语句快速检索数据，特别是在将一些更多“事务/更改”表连接在一起的情况下。

编辑2:表之间的连接通常都是在主键和外键之间，对于具有外键的表，它们被包含在非聚集索引中以提供更具覆盖性的索引。

所有表都没有其他可以提供良好聚集索引的值。

我更倾向于在每个高负载表上添加一个额外的标识列，然后将当前的 Guid PK 列包含在聚集索引中，以提供最佳的查询性能。

编辑3:我估计 80% 的查询是通过数据访问机制单独对主键和外键执行的。一般来说，我们的数据模型具有延迟加载的对象，这些对象在访问时执行查询，这些查询使用对象 id 和 PK 列。我们有大量用户驱动的数据排除/包含查询，这些查询使用外键列作为基于类型 X 排除以下 id 的条件的过滤器。剩下的20%是Enum(int)或日期范围列上的where子句，系统中很少执行基于文本的查询。

在可能的情况下，我已经添加了覆盖索引来覆盖最繁重的查询，但到目前为止我仍然对性能感到失望。正如 bluefooted 所说，数据被存储为堆。

Answer 1

如果表上没有聚集索引，它将存储为堆而不是 B 树。堆数据访问在 SQL Server 中绝对是非常糟糕的，因此您肯定需要添加聚集索引。

我同意您的分析，即 GUID 列对于聚类来说是一个糟糕的选择，特别是因为您无法使用 NEWSEQUENTIALID()。如果您愿意，您可以创建一个新的人工整数键，但如果有另一列或列组合可以作为聚集索引，那也可以。

您是否有一个经常用于范围扫描的字段？哪些列用于连接？除了 GUID 之外，是否存在也唯一标识行的列组合？发布数据模型的示例将帮助我们推荐一个好的聚类候选者。