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

Question

好.我已经在这里和那里读过关​​于SQL Server堆的东西,但没有什么太明确的真正指导我.我将尝试衡量绩效,但希望能就我应该研究的内容提供一些指导.这是SQL Server 2008 Enterprise.以下是表格:

工作

• JobID(PK,GUID,外部生成)
• StartDate(datetime2)
• 帐户ID
• 几个会计字段,主要是小数和bigints

JobSteps

• JobStepID(PK,GUID,外部生成)
• JobID FK
• 开始日期
• 几个会计字段,主要是小数和bigints

用法:大量插入(数百/秒),每个作业通常为1个JobStep.估计每月可能有100-200M行.根本没有更新,唯一的删除来自3个月以前的归档数据.

对数据执行~10次查询/秒.有些人将JobSteps加入乔布斯,有些人只看乔布斯.几乎所有查询都在StartDate上,其中大多数包括AccountId和一些其他会计字段(我们有它们的索引).查询非常简单 - 执行计划的最大部分是JobSteps的连接.

优先级是插入性能.有些滞后(大约5分钟左右)可以容忍数据出现在查询中,因此复制到其他服务器并运行查询肯定是允许的.

除了将JobSteps加入Jobs之外,基于GUID的查找非常罕见.

当前设置:没有聚集索引.唯一一个似乎是候选者的是StartDate.但是,它并没有完美地增加.可以在StartDate后的3小时窗口中将作业插入任何位置.这可能意味着按照非最终的顺序插入了一百万行.

使用我当前索引的1 Job + 1 JobStepId的数据大小约为500字节.

问题:

• 这是一个很好用的堆？

• 群集在StartDate上有什么影响,当它几乎是非连续的~2小时/ 100万行？我的猜测是不断的重新排序会杀死插入性能.

• 我是否应该添加bigint PK只是为了拥有更小,总是增加的密钥？(我仍然需要guid进行查找.)

我将GUID作为PRIMARY KEYs和/或集群键读取,它似乎表明即使发明密钥也会在其他索引上节省大量空间.另外一些资源表明堆通常存在某种性能问题,但我不确定它是否仍然适用于SQL 2008.

再次,是的,我将尝试进行测试和测量.我只是想获得一些指导或链接到其他文章,这样我就可以考虑哪些路径做出更明智的决定.

Answer 1

是的,堆有问题.您的数据将在整个节目中按逻辑分段,并且不能简单地进行碎片整理.

想象一下,把你所有的电话簿扔进一个桶里然后试图找到"bob smith".或者使用带有lastname,firstname上的聚簇索引的传统电话目录.

维护索引的开销很小.

StartDate,除非是唯一的,不是一个好的选择.聚簇索引需要非聚集索引的内部唯一性.如果没有声明唯一,SQL Server将添加一个4字节的"uniquifier".

是的,我使用int或bigint来简化它.至于GUID:请参阅屏幕右侧的问题.

编辑:

注意,PK和聚簇索引是2个单独的问题,即使SQL Server是默认的也会使PK聚集.