在主键/ Clusted索引中使用GUID

Question

我非常精通SQL服务器性能,但我不得不争辩说GUID应该被用作Clusterd主键的默认类型.

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

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

我为所有问题道歉,但我希望得到一些备份,因为不使用GUID作为PK的默认值.然而,我完全愿意通过StackOverflow用户群的过度知识改变我的想法.

Answer 1

如果您正在进行任何类型的卷,除非您使用顺序GUID,否则GUID非常糟糕,因为您描述的确切原因.页面碎片很严重:

                 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和整数之间的比较显示:

Test1导致了大量的页面拆分,并且在插入完成后运行DBCC SHOWCONTIG时扫描密度大约为12%.Test2表的扫描密度约为98%

但是,如果你的音量非常低,那就没那么重要了.

如果确实需要全局唯一ID但具有高容量(并且不能使用顺序ID),只需将GUID放在索引列中即可.