我们正在开发一个非常大的OLTP数据库（SQL server 2012）并考虑使用GUID作为主键（我记住不要让它聚集在一起），但是，我们不确定后果特别是性能。我们首先使用EF代码。
有人可以帮我们决定吗？请附上文章链接。感谢
答案 0 :(得分：4)
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相同的问题 - 只是不那么显着。< / p>
然后还有另一个需要考虑的问题：表格上的聚类键也会被添加到表格中每个非聚集索引的每个条目上 - 因此你真的想确保它尽可能小。通常，对于绝大多数表来说，具有2亿行的INT应该足够 - 并且与作为群集密钥的GUID相比，您可以在磁盘和服务器内存中节省数百兆的存储空间。
快速计算 - 使用INT与GUID作为主要和群集密钥：
TOTAL：25 MB vs. 106 MB - 这只是在一张桌子上！
更多值得思考的东西 - 金佰利特里普的优秀作品 - 阅读，再读一遍，消化它！这是SQL Server索引福音，真的。