Sql server 2008 SQL GUID与整数

我最近开始了一项新工作，并注意到所有SQL表都使用GUID数据类型作为主键

在我以前的工作中，我们使用整数（自动递增）作为主键，在我看来，使用它要容易得多

例如，假设您有两个相关的表；Product和ProductType—我可以很容易地交叉检查两个表的“ProductTypeID”列中的某一行，以快速映射我头脑中的数据，因为它很容易存储数字（2,4,45等），而不是（E75B92A3-3299-4407-A913-C5CA196B3CAB）

额外的挫折来自我想要理解表之间的关系，遗憾的是没有数据库图：(

很多人说GUID更好，因为您可以在C#代码中定义唯一的标识符，例如使用NewID（）而不需要SQL SERVER来定义它-这也允许您临时知道ID是什么…但是我发现仍然可以检索“下一个自增整数”

一位DBA承包商报告说，如果我们使用整数类型而不是GUID，我们的查询速度可以提高30%

---

为什么存在GUID数据类型，它真正提供了什么优势？…即使某些专业人士选择了它，也必须有一些很好的理由来解释为什么要实现它？

在某些情况下，GUID可以用作标识字段：

• 当您有多个SQL实例（不同的服务器）并且以后需要在不影响引用完整性的情况下组合不同的更新时
• 创建数据的断开连接的客户端—这样，他们就可以创建数据，而不用担心ID字段已被占用

---

生成的GUID是全局唯一的，这就是为什么它们适合于这种情况。

它是全局唯一的，因此表中的每个记录都有一个GUID，世界上没有其他任何类型的项共享。如果需要这种排他标识，请使用它（如果您正在复制数据库，或组合来自多个源的数据）。否则，您的dba是正确的-GUID比整数大得多，效率也低得多，并且您可以提高db的速度（30%？可能…）

它们基本上可以让您避免使用更复杂的逻辑

set @InsertID = scope_identity() 

---

有很多关于使用guid作为PKs的Google-able文章，几乎所有这些文章都说了与DBA承包商所说的相同的话——没有guid作为键，查询速度更快

我在实践中看到的主要用途（我们从未将它们用作PKs）是复制。的MSDN页面上也有类似的说明。

INT

优点：

在联接、索引和条件中使用数值（特别是整数）时，性能更好。 如果显示数值，则应用程序用户更容易理解这些数值

缺点：

如果您的表很大，它很可能会用完，并且在一些数字值之后，将不会使用其他标识

GUID

优点：

在服务器上是唯一的

缺点：

在连接、索引和条件中使用字符串值时，其性能不如整数值最佳。 需要比INT更多的存储空间

---

值得赞扬的是：

与这里大多数人所宣扬的相反，我认为GUID更多的是一种瘟疫而不是一种祝福。原因如下：

GUID似乎是主键的自然选择—如果您确实需要，您可能会争论将其用作表的主键。我强烈建议不要做的是将GUID列用作群集键，SQL Server默认情况下会这样做，除非您明确告诉它不要这样做

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

主键是一个逻辑结构-唯一且可靠地标识表中每一行的候选键之一。实际上，它可以是任何内容-一个INT、一个GUID、一个字符串-选择对您的场景最有意义的内容

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

默认情况下，SQL Server表上的主键也用作群集键-但不需要这样！我个人看到，将以前基于GUID的主键/群集键拆分为两个单独的键（GUID上的主键（逻辑键）和群集（顺序键）时，性能大幅度提高在单独的INT-IDENTITY（1,1）列上输入

正如《索引女王》和其他人多次指出的那样，作为集群键的GUID并不是最优的，因为由于其随机性，它将导致大量页面和索引碎片，并导致总体性能不佳

是的，我知道-在SQL Server 2005和更高版本中有

newsequentialid（）

-但即使这样也不是真正的完全顺序的，因此也会遇到与GUID相同的问题-只是不太明显。另外，您只能将其用作表中列的默认值-您无法在T-SQL代码中获得新的顺序GUID（像扳机之类的）-另一个主要缺点

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

快速计算-使用INT vs.GUID作为主键和群集键：

• 基表wi