我有一个新的应用程序，我想使用GUID作为我的集群表的主键。我听说使用newid（）有不利之处，所以我想了解更多关于newsequentialid（）的信息。
使用int对newsequentialid（）生成的guid有什么好处。
答案 0 :(得分：8)
GUID似乎是您主键的自然选择 - 如果您真的必须，您可能会争辩将其用于表的PRIMARY KEY。我强烈建议不要使用GUID列作为群集密钥，默认情况下SQL Server会执行此操作，除非您明确指出到。
你真的需要分开两个问题：
主键是一个逻辑结构 - 唯一且可靠地标识表中每一行的候选键之一。这可以是任何事情，真的 - INT，GUID，字符串 - 选择对您的方案最有意义的内容。
群集密钥（在表上定义“聚簇索引”的一列或多列） - 这是与物理存储相关的东西，并且在这里，一个小而稳定，不断增加的数据类型是您的最佳选择 - INT或BIGINT作为您的默认选项。
默认情况下，SQL Server表上的主键也用作群集键 - 但这不一定是这样！我个人看到在将先前基于GUID的主/群集密钥分解为两个单独的密钥（GUID上的主（逻辑）密钥和单独的{上的集群（排序）密钥）时可以获得巨大的性能提升{1}}列。
作为Kimberly Tripp - 索引女王 - 以及其他人已多次声明 - 由于群集密钥不是最佳的INT IDENTITY(1,1)随机性，它将导致大量的页面和索引碎片，并导致一般性能不佳。
是的，我知道 - 在SQL Server 2005及更高版本中有GUID - 但即使这样也不是真正完全顺序的，因此也遇到与newsequentialid()相同的问题 - 只是少了一点显着如此。
然后还有另一个需要考虑的问题：表格上的聚类键也会被添加到表格中每个非聚集索引的每个条目上 - 因此你真的想确保它尽可能小。通常，对于绝大多数表来说，具有2亿行的GUID应该足够 - 并且与作为群集密钥的INT相比，您可以在磁盘上保存数百兆字节的存储空间。服务器内存。
快速计算 - 使用GUID与INT作为主要和群集密钥：
TOTAL：25 MB vs. 106 MB - 这只是在一张桌子上！
更多值得思考的东西 - 金佰利特里普的优秀作品 - 阅读，再读一遍，消化它！这是SQL Server索引福音，真的。
马克