我们有一个数据库，其中所有 PK 都是 GUID，大多数 PK 也是表的聚集索引。我们知道这很糟糕（由于 GUID 的随机性）。因此，这里似乎基本上有两种选择（没有将 GUID 作为 PK 完全丢弃，我们不能这样做（至少目前不是））。
在这种情况下是否可以给出任何一般性建议？
有问题的应用程序有 500 多个表，目前最大的一个大约有 150 万行，一些表大约 500 000 行，其余的则显着减少（其中大多数远低于 10K）。
此外，该应用程序已安装在多个客户站点，因此我们必须考虑对现有客户可能产生的任何负面影响。
谢谢！
【问题讨论】：
标签： sql-server guid uniqueidentifier clustered-index
我的意见很明确：使用 INT IDENTITY 作为集群键。这是迄今为止最好、最优的聚类键，因为它：
顺序 GUID 肯定比常规随机 GUID 好得多，但仍然比 INT 大四倍（16 字节对 4 字节），如果表中有很多行，并且有很多非-该表上的聚集索引也是如此。集群键被添加到每个非聚集索引中，因此显着增加了 16 字节与 4 字节大小的负面影响。更多字节意味着磁盘和 SQL Server RAM 中的页面更多，因此磁盘 I/O 和 SQL Server 的工作量也更多。
在适当的情况下，您绝对可以将 GUID 保留为主键 - 但在这种情况下，我强烈建议向该表添加一个单独的 INT IDENTITY 并将该 INT 作为集群键。我自己用一些大表完成了这项工作，结果令人惊讶 - 表碎片从 99% 和更多的百分比下降到几个百分比，并且性能要好得多。
在此处查看 Kimberly Tripp 关于为什么 GUID 在 SQL Server 中作为群集键不好的优秀系列：
马克
【讨论】：
如果您能够轻松地将您的 guid 生成更改为顺序 guid 生成，那么这可能是您的速赢选择。顺序 guid 将停止表上的碎片，同时保留为您的聚集索引。不过，顺序 guid 的主要缺点是它们变得容易猜测，这通常是不希望的，也是首先使用 guid 的原因。
如果你为你的聚集主键沿着标识路线走，然后只是你的 guid 列上的一个索引，那么你的 guid 索引上仍然会出现很多碎片。然而，表格将不再碎片化这一事实将是一个巨大的收获。
最后，我知道你说你现在不能这样做，但是，如果你根本不需要使用 guid 作为索引，那么你就可以解决所有这些问题。
【讨论】：