将 int 或 newsequentialid 用于聚簇表主键有哪些优点/缺点？

Question

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

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

Answer 1

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

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

1. 主键 是一种逻辑结构 - 候选键之一，可唯一且可靠地标识表中的每一行。这可以是任何东西，真的——INT、GUID、字符串——选择对你的场景最有意义的东西。

2. clustering key（定义表中“聚集索引”的一列或多列） - 这是一个与存储相关的物理事物，并且在这里，一个小的、稳定的、不断增长的数据类型是您的最佳选择 - 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 vs. 106 MB - 这只是在一张桌子上！

更多值得深思的东西 - 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!

马克