在主键/聚类索引中使用GUID

Question

我精通SQL server性能，但我不得不反驳GUID应该用作Clusterd主键的默认类型的想法。

假设该表每天的插入量相当低(5000 +/-行/天)，我们会遇到什么样的性能问题？页面拆分将如何影响我们的seek性能？我应该多久重建一次索引(或者我应该整理一次碎片整理)？我应该将填充因子设置为多少(100、90、80等)？

如果我每天插入1,000,000行会怎么样？

我为所有的问题道歉，但我希望得到一些支持，因为我没有使用GUID作为我们的默认PKs。然而，我完全愿意让来自StackOverflow用户群的强大知识改变我的想法。

Answer 1

如果你正在做任何类型的卷，GUID作为PK是非常糟糕的，除非你使用sequential GUIDs，原因和你描述的完全一样。Page fragmentation is severe

                 Average                    Average
                 Fragmentation  Fragment    Fragment   Page     Average 
Type             in Percent     Count       Size       Count    Space Used

id               4.35           7           16.43      115      99.89
newidguid        98.77          162         1          162      70.90 
newsequentualid  4.35           7           16.43      115      99.89

正如GUID和整数之间的this comparison所示：

Test1导致了大量的页面拆分，当我在插入完成后运行DBCC SHOWCONTIG时，扫描密度约为12%。Test2工作台具有约98%扫描密度

但是，如果你的音量很低，那就没什么关系了。

如果您确实需要一个全局惟一的ID，但是有大量的内容(并且不能使用顺序ID)，那么只需将GUID放在一个索引列中即可。

Answer 2

使用GUID作为主键的缺点：

• 没有意义的排序，意味着索引不会像处理整数那样提高性能。
• GUID的大小为16字节，而整数的大小为2、4或8字节。
• 人类很难记住，因此不适合作为引用id。

优势：

• 允许不可猜测的主键，因此在不提供自动增量或标识数据类型的数据库中显示在网页查询字符串或application.
• Useful中时，这种主键的危险性较小。当您需要在跨平台或environments.

的两个不同数据源之间连接数据时，

• 非常有用

我认为决定是否使用GUID非常简单，但可能我没有意识到其他问题。

Answer 3

由于每天的插入次数如此之少，我怀疑页面拆分是否应该是一个重要的因素。真正的问题是，5000与现有的行数相比如何，因为这将是决定适当的初始填充因子以推迟拆分所需的主要信息。

也就是说，我个人并不是GUID的狂热粉丝。我知道它们在某些情况下可以很好地服务，但在许多情况下，它们只是效率的“拦路虎”，易用性，……

我发现以下问题有助于确定是否应该使用GUID。

• 主键是否会被共享/发布？(例如，它是否会在SQL内部使用之外使用，应用程序是否需要以某种持久的方式使用这些键？用户会以某种方式看到这些键吗？
• 可以使用PK来帮助合并不同的数据源吗？
• 表中是否有由数据中的列组成的主要-possibly组合？这个键的大小是多少，

，

• ，主键是如何排序的？如果是复合的，前几列是选择性的吗?