0

我们正在开发一个非常大的 OLTP 数据库（SQL server 2012），并考虑使用 GUID 作为主键（我要记住不要使其集群化），但是，我们不确定特别是性能的后果。我们首先使用 EF 代码。

有人可以帮我们决定吗？请包括文章链接。谢谢

4

1 回答 1

4

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

您确实需要将两个问题分开：

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

  2. 聚集键（在表上定义聚集索引的一列或多列）——这是一个与物理存储相关的东西，在这里，一个小的、稳定的、不断增长的数据类型是你最好的选择——INT或者BIGINT作为你的默认选项.

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

正如Kimberly Tripp - 索引女王 - 和其他人多次声明的那样 - 作为集群键的 GUID 并不是最优的，因为由于它的随机性，它会导致大量的页面和索引碎片以及通常糟糕的性能。

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

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

快速计算 - 使用INTvs. GUID 作为主键和聚类键：

  • 具有 1'000'000 行的基表（3.8 MB 与 15.26 MB）
  • 6 个非聚集索引（22.89 MB 与 91.55 MB）

总计：25 MB 与 106 MB - 这只是在一张桌子上！

更多值得深思的东西——金伯利·特里普（Kimberly Tripp）的优秀作品——读一读，再读一遍，消化一下！这是 SQL Server 索引的福音，真的。

于 2013-02-21T06:43:09.227 回答