我非常精通sql服务器性能,但我不得不争辩说GUID应该被用作Clusterd主键的默认类型.
假设该表每天的插入量相当少(5000 / – 行/天),我们可能会遇到什么样的性能问题？页面拆分将如何影响我们的搜索性能？我应该多久重新索引(或者我应该整理碎片)？我应该将填充因子设置为(100,90,80等)？
如果我每天插入1,000,000行怎么办？
我为所有问题道歉,但我希望得到一些备份,因为不使用GUID作为PK的默认值.然而,我完全愿意通过StackOverflow用户群的过度知识改变我的想法.
解决方法
如果您正在进行任何类型的卷,除非您使用
sequential GUIDs,否则GUID非常糟糕,因为您描述的确切原因.
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 caused a tremendous amount of page splits,and had a scan density around 12% when I ran a DBCC SHOWCONTIG after the inserts had completed. The Test2 table had a scan density around 98%
但是,如果你的音量非常低,那就没那么重要了.
如果确实需要全局唯一ID但具有高容量(并且不能使用顺序ID),只需将GUID放在索引列中即可.
