Uniqueidentifier PK：SQL Server 堆是正确的选择吗？

Question

好的。我已经在这里和那里阅读了有关 SQL Server 堆的内容，但没有什么太确定而无法真正指导我。我将尝试衡量性能，但希望对我应该研究的内容提供一些指导。这是 SQL Server 2008 企业版。以下是表格：

工作

• JobID（PK、GUID、外部生成）
• 开始日期（日期时间2）
• 账户ID
• 更多会计字段，主要是小数和大整数

工作步骤

• JobStepID（PK、GUID、外部生成）
• JobID FK
• 开始日期
• 更多会计字段，主要是小数和大整数

用法：大量插入（数百次/秒），通常每个作业 1 个 JobStep。估计每月可能有 100-200M 行。根本没有更新，唯一的删除来自归档超过 3 个月的数据。

对数据执行约 10 次查询/秒。有的加入 JobSteps 到 Jobs，有的只看 Jobs。几乎所有查询都将在 StartDate 上进行，其中大多数包括 AccountId 和其他一些会计字段（我们对它们有索引）。查询非常简单 - 执行计划的最大部分是 JobSteps 的连接。

优先级是插入性能。数据出现在查询中的延迟（5 分钟左右）是可以容忍的，因此复制到其他服务器并在它们之外运行查询当然是允许的。

除了将 JobSteps 加入到 Jobs 之外，基于 GUID 的查找非常少见。

当前设置：没有聚集索引。唯一看起来像候选人的是 StartDate。但是，它并没有完美地增加。可以在 StartDate 之后的 3 小时窗口内的任何位置插入作业。这可能意味着以非最终顺序插入一百万行。

1 个 Job + 1 个 JobStepId 的数据大小，使用我当前的索引，大约是 500 字节。

问题：

• 这对堆有用吗？

• 集群对 StartDate 的影响是什么，当它在大约 2 小时/100 万行中几乎没有顺序时？我的猜测是不断的重新排序会杀死插入性能。

• 我是否应该只添加 bigint PK 来获得更小的、总是增加的键？ （我仍然需要用于查找的指南。）

我读过GUIDs as PRIMARY KEYs and/or the clustering key，它似乎暗示即使发明一个键也可以在其他索引上节省大量空间。还有一些资源表明堆通常存在某种性能问题，但我不确定这是否仍然适用于 SQL 2008。

再一次，是的，我将尝试执行测试和测量。我只是想获得一些指导或指向其他文章的链接，以便我可以就要考虑的路径做出更明智的决定。

Answer 1

是的，堆有问题。您的数据将在整个节目中逻辑碎片化，不能简单地进行碎片整理。

想象一下，把你所有的电话簿都扔进一个桶里，然后试图找到“bob smith”。或者使用对姓氏、名字有聚集索引的传统电话簿。

维护索引的开销是微不足道的。

StartDate 除非是唯一的，否则不是一个好的选择。聚集索引需要非聚集索引的内部唯一性。如果未声明唯一，SQL Server 将添加一个 4 字节的“唯一性”。

是的，我会使用 int 或 bigint 来简化它。至于 GUID：请参阅屏幕右侧的问题。

编辑：

注意，PK 和聚集索引是 2 个独立的问题，即使默认 SQL Server 会使 PK 聚集。

Answer 2

堆碎片不一定是世界末日。听起来您很少会扫描数据，所以这不是世界末日。

您的非聚集索引会影响您的性能。每个都需要将行的地址存储在底层表（堆或聚集索引）中。理想情况下，您的查询永远不必使用基础表本身，因为它以理想的方式存储所需的所有信息（包括所有列，因此它是一个覆盖索引）。

是的，Kimberly Tripp 的东西是最好的索引。

罗伯

Answer 3

正如您自己的研究和所有其他回答者所提到的，使用 GUID 作为表上的聚集索引是个坏主意。

但是，拥有堆也不是一个好的选择，因为堆还有其他问题，主要与碎片和其他无法与堆一起使用的问题有关。

我的最佳实践建议总是这样：

• 请在任何数据表上使用主键、聚集键（除非它是临时表或用于批量加载的表）
• 尝试确保集群键是 INT IDENTITY 或 BIGINT IDENTITY

我认为通过添加 INT/BIGINT 获得的好处——即使只是为了拥有一个好的聚集索引——也远远超过了它的缺点（正如 Kim Tripp 在你引用的她的博客文章中所说的那样）。

马克

Answer 4

由于 GUId 是您的主键和外键，您的数据库仍需要检查每个插入的约束，您可能需要为其编制索引。不建议对 GUId 进行索引，因为它具有随机性。因此，我绝对要说，您应该为您的主键使用 bigint（可能是标识）路线并将其用作聚集索引。