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

Question

我们有一个旧数据库，即 sql server 数据库（2005 年和 2008 年）。

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

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

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

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

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

即

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

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

Q1：这会提高数据库的查询性能还是会降低数据库的查询性能？

Q2：是否有我未列出的替代方案？

谢谢 Pete

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

我不确定您的 GUID 来自哪里，但如果它们是在插入期间使用 NEWSEQUENTIALID() 而不是 NEWID() 将帮助您避免插入期间的碎片问题。

关于聚集索引的选择，正如 Kimberly L. Tripp 所说 这里：“选择聚集索引最重要的因素是它的唯一性、狭窄性和静态性（不断增加对于最小化分裂还有其他好处）。”与 INT 甚至 BIGINT 相比，GUID 无法满足狭窄的要求。

Kimberly 还有一篇关于 GUID 作为主键和/或集群键。

Answer 3

我不是 100% 清楚：您的第 1 号访问模式是通过 GUID 还是通过其他列查询表？当连接到其他表时，最常使用哪些列（和数据类型）？

在我进一步了解这些 GUID 的使用方式之前，我无法真正为您提供任何可靠的建议。我知道您说过它们是主键，但这并不能保证它们用作查询或连接的主要条件。

更新

现在我知道了更多一点，我有一个疯狂的建议。对 GUID 上的这些表进行聚类，但将填充因子设置为 60%。这将改善页面拆分问题，并为您提供更好的对这些小狗的查询性能。

至于使用Guid.NewGuid()，看来你毕竟可以在C#中执行sequentialGUID。我在 SO 上找到了以下代码：

[DllImport("rpcrt4.dll", SetLastError = true)]
static extern int UuidCreateSequential(out Guid guid);

public static Guid SequentialGuid()
{
    const int RPC_S_OK = 0;
    Guid g;
    if (UuidCreateSequential(out g) != RPC_S_OK)
        return Guid.NewGuid();
    else
        return g;
}

newsequentialID() 实际上只是 UuidCreateSequential 的包装。我确信如果您不能直接在客户端上使用它，您可以找到一种方法来快速往返服务器以从那里获取新的顺序 ID，甚至可以使用“分配器”表和存储过程来完成这项工作。

Answer 4

您没有指出您的性能问题是什么。如果性能最差的操作是 INSERT，那么也许您的解决方案是正确的。如果是其他事情，那么我会看看聚集索引如何提供帮助。

您可以查看表上的现有索引以及使用它们的查询。您也许可以选择一个索引，虽然它会稍微降低 INSERT 的性能，但可以为当前的性能问题区域提供更大的好处。