顺序引导和碎片

Question

我试图了解顺序 guid 的性能如何比常规 guid 更好。

是否因为使用常规 guid，索引使用 guid 的最后一个字节进行排序？由于它是随机的，因此会导致大量碎片和页面拆分，因为它经常将数据移动到另一个页面以插入新数据？

顺序引导正弦它是顺序的，它会导致更少的页面分割和碎片吗？

我的理解正确吗？

如果有人能够对这个主题有更多的了解，我将非常感激。

谢谢

编辑：

顺序 guid = NEWSEQUENTIALID()，

常规 guid = NEWID()

Answer 1

你在问题中已经说得差不多了。

使用顺序 GUID/主键，新行将被添加到表的末尾，这使得 SQL Server 的事情变得简单。相比之下，随机主键意味着新记录可以插入表中的任何位置 - 表的最后一页在缓存中的可能性相当大（如果这是所有读取的位置），但是缓存中表中间的随机页相当低，这意味着需要额外的 IO。

最重要的是，当将行插入到表的中间时，可能没有足够的空间来插入额外的行。如果是这种情况，那么 SQL Server 需要执行额外昂贵的 IO 操作，以便为记录创建空间 - 避免这种情况的唯一方法是在数据之间分散间隙，以允许插入额外的记录（称为填充因子），这本身会导致性能问题，因为数据分布在更多页面上，因此需要更多 IO 来访问整个表。

Answer 2

我尊重 Kimberly L. Tripp 在这个话题上的智慧：

但是，GUID 不是连续的 -
就像一个有自己价值观的人
在客户端生成（使用.NET）
OR 由 newid() 函数生成
（在 SQL Server 中）可能会非常糟糕
选择——主要是因为
它产生的碎片
基表还因为它
尺寸。它不必要地宽（它是 4
比基于 int 的身份宽几倍
- 可以为您提供 20 亿（实际上是 40 亿）唯一行）。和，
如果你需要超过20亿你
总是可以使用 bigint （8 字节
int) 并获得 263-1 行。

阅读更多： http://www.sqlskills.com/BLOGS/KIMBERLY/post/GUIDs-as-PRIMARY-KEYs-andor-the-clustering-key.aspx#ixzz0wDK6cece

Answer 3

要可视化整个图片名为ostress的util可能是用过的。
例如，您可以创建两个表：一个使用正常 GUID 作为 PK，另一个使用顺序 GUID：

-- normal one
CREATE TABLE dbo.YourTable(
   [id] [uniqueidentifier] NOT NULL,
   CONSTRAINT [PK_YourTable] PRIMARY KEY NONCLUSTERED (id)
);
-- sequential one
CREATE TABLE dbo.YourTableSeq(
   [id] [uniqueidentifier] NOT NULL CONSTRAINT [df_yourtable_id]  DEFAULT (newsequentialid()),
   CONSTRAINT [PK_YourTableSeq] PRIMARY KEY NONCLUSTERED (id)
);

然后使用给定的 util，您可以选择有关索引碎片的统计信息来运行大量插入：

ostress -Slocalhost -E -dYourDB -Q"INSERT INTO dbo.YourTable VALUES (NEWID()); SELECT count(*) AS Cnt FROM dbo.YourTable; SELECT AVG_FRAGMENTATION_IN_PERCENT AS AvgPageFragmentation, PAGE_COUNT AS PageCounts FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, N'LIMITED') DPS INNER JOIN sysindexes SI ON DPS.OBJECT_ID = SI.ID AND DPS.INDEX_ID = SI.INDID WHERE SI.NAME = 'PK_YourTable';" -oE:\incoming\TMP\ -n1 -r10000

ostress -Slocalhost -E -dYourDB -Q"INSERT INTO dbo.YourTableSeq DEFAULT VALUES; SELECT count(*) AS Cnt FROM dbo.YourTableSeq; SELECT AVG_FRAGMENTATION_IN_PERCENT AS AvgPageFragmentation, PAGE_COUNT AS PageCounts FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, N'LIMITED') DPS INNER JOIN sysindexes SI ON DPS.OBJECT_ID = SI.ID AND DPS.INDEX_ID = SI.INDID WHERE SI.NAME = 'PK_YourTableSeq';" -oE:\incoming\TMP\ -n1 -r10000

然后在文件 E 中： \incoming\TMP\query.out 您将找到您的统计信息。
我的结果是：

"Normal" GUID:
Records    AvgPageFragmentation     PageCounts           
---------------------------------------------- 
1000       87.5                     8                    
2000       93.75                    16                   
3000       96.15384615384616        26                   
4000       96.875                   32                   
5000       96.969696969696969       33                   
10000      98.571428571428584       70                   


Sequential GUID:
Records    AvgPageFragmentation     PageCounts           
---------------------------------------------- 
1000       83.333333333333343       6                    
2000       63.636363636363633       11                   
3000       41.17647058823529        17                   
4000       31.818181818181817       22                   
5000       25.0                     28                   
10000      12.727272727272727       55       

正如您所看到的，插入顺序生成的 GUID 时，索引的碎片要少得多，因为插入操作导致新页面分配更少。