具有群集GUID PK的SQL Server数据库 - 切换聚簇索引还是切换到顺序(梳状)GUID？

Question

我们有一个数据库,其中所有PK都是GUID,大多数PK也是表的聚簇索引.我们知道这很糟糕(由于GUID的随机性).因此,似乎这里基本上有两个选项(完全没有将GUID作为PK扔掉,这是我们做不到的(至少目前不是这样)).

• 我们可以改变GUID生成算法,例如是NHibernate的使用,如详细介绍了一个这篇文章,或
• 对于最重要的表,我们可以更改为不同的聚簇索引,例如IDENTITY列,并将"随机"GUID保留为PK.

是否有可能在这种情况下提供任何一般性建议？

该应用程序有500多个表,最大的一个目前约150万行,几个表约50万行,其余表显着较低(大多数低于10K).

此外,该应用程序已安装在多个客户站点,因此我们必须考虑现有客户的任何可能的负面影响.

谢谢!

Answer 1

我的观点很明确:对集群密钥使用INT IDENTITY.这是迄今为止最好,最优的群集密钥,因为它:

• 小
• 稳定(永远不要改变)
• 独特
• 不断增加

顺序GUID肯定比常规随机GUID好很多,但是仍然比INT大16倍(16比4字节),如果你的表中有很多行,这将是一个因素,以及许多非聚集索引在那张桌子上也是.聚类键被添加到每个非聚集索引中,因此显着增加了16个大小与4个字节的负面影响.更多字节意味着磁盘和SQL Server RAM中的页面越多,因此更多的磁盘I/O和更多的SQL Server工作.

在适当的情况下,您绝对可以将GUID保留为主键 - 但在这种情况下,我强烈建议为该表添加单独的INT IDENTITY,并使该INT成为群集密钥.我自己已经完成了许多大型表格,结果令人惊讶 - 表格碎片率从99%降低到百分之几,性能更好.

查看Kimberly Tripp关于为什么GUID在SQL Server中作为群集密钥不好的优秀系列:

• GUID作为PRIMARY KEY和/或聚类键
• 集群指数辩论继续......
• 不断增加的聚类密钥 - 聚集索引辩论..........再次!

渣

Answer 2

如果您能够轻松地将 guid 生成更改为顺序 guid 生成，那么这可能是您的快速获胜选择。顺序 guid 将停止表上的碎片，同时保留为聚集索引。然而，顺序引导的主要缺点是它们会变得可猜测，这通常是不希望的，这也是首先使用引导的原因。

如果您沿着聚集主键的身份路径，然后仅在 guid 列上建立索引，那么您的 guid 索引上仍然会出现大量碎片。然而，表将不再碎片化这一事实将是一个巨大的收获。

最后，我知道你说过你现在不能这样做，但是，如果你根本不需要使用 guid 作为索引，那么你就可以消除所有这些问题。