sql - 对聚簇表主键使用 int 或 newsequentialid 有什么优点/缺点？

我有一个新应用程序，我想使用 GUID 作为我的聚簇表的主键。我听说使用 newid() 有缺点，所以我想了解更多关于 newsequentialid() 的信息。

具体来说，与使用 newsequentialid() 生成的 guid 相比，使用 int 有什么优势。

最佳答案

GUID 似乎是您的主键的自然选择 - 如果您真的必须这样做，您可能会争辩说将它用于表的 PRIMARY KEY。我强烈建议 不要做 是使用 GUID 列作为 群集键 ，SQL Server 默认情况下这样做，除非您明确告诉它不要这样做。

你真的需要把两个问题分开:

主键 是一个逻辑结构 - 唯一且可靠地标识表中每一行的候选键之一。这可以是任何东西，真的 - 一个 INT ，一个 GUID ，一个字符串 - 选择最适合您的场景的内容。

聚集键 (定义表上“聚集索引”的一列或多列)——这是一个物理存储相关的东西，在这里，一个小的、稳定的、不断增加的数据类型是你最好的选择—— INT 或 BIGINT 作为您的默认选项。

默认情况下，SQL Server 表上的主键也用作集群键 - 但不必如此!当将之前的基于 GUID 的主键/集群键分解为两个单独的键时，我个人看到了巨大的性能提升 - GUID 上的主(逻辑)键和单独 INT IDENTITY(1,1) 列上的集群(排序)键。

正如 Kimberly Tripp - 索引女王 - 和其他人多次说过 - GUID 作为集群键不是最佳的，因为由于它的随机性，它会导致大量的页面和索引碎片，并且通常会导致性能不佳。

是的，我知道 - 在 SQL Server 2005 及更高版本中有 newsequentialid() - 但即使这样也不是真正和完全连续的，因此也遇到与 GUID 相同的问题 - 只是不那么突出。

然后还有另一个问题需要考虑:表上的聚簇键也将添加到表上每个非聚簇索引的每个条目中 - 因此您确实希望确保它尽可能小。通常，具有 2+ 十亿行的 INT 应该足以满足绝大多数表 - 与作为集群键的 GUID 相比，您可以在磁盘和服务器内存上节省数百兆字节的存储空间。

快速计算 - 使用 INT 与 GUID 作为主键和聚类键:

具有 1'000'000 行的基表(3.8 MB 与 15.26 MB)

6 个非聚集索引(22.89 MB 与 91.55 MB)

总计:25 MB 与 106 MB - 这只是在一张 table 上!

还有一些值得深思的东西——金伯利·特里普 (Kimberly Tripp) 的优秀作品——阅读、再读、消化!这是 SQL Server 索引的福音，真的。

GUIDs as PRIMARY KEY and/or clustered key

The clustered index debate continues

Ever-increasing clustering key - the Clustered Index Debate..........again!

Disk space is cheap - that's not the point!

马克

关于sql - 对聚簇表主键使用 int 或 newsequentialid 有什么优点/缺点？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/29507777/