asp.net - SQL 主键

Question

因此，我和一位同事正在争论哪种方式更适合生成 GUID 主键。

我们将 .NET 4.0 与 Entities 4 结合使用，并使用存储过程进行选择/插入/更新。

他想要在代码中创建 GUID 主键，并使用 Guid 类或/和使用某些创建的 Sequential GUID 类将其作为插入的一部分传递回来。

我希望 SQL Server 在插入时使用 newid() 或 newsequentialid() 创建 GUID。

我反对他的方法的论点是，如果您必须执行多次插入，则必须进行往返才能为每个插入获取一个 guid，以便维护外键约束的关系。另外，使用这种方式，您必须为每个插入进行多次往返。

他关于使用 SQL 的论点是，在插入发生之前他无权访问该键，并且必须等待插入发生才能将主键 guid 重新用于代码的其他部分。通过这种方式，您可以与存储过程建立一个连接，并由它处理所有插入。

那么，哪种方法对于单次插入更好？对于事务中的多次插入，哪种方法更好？

Answer 1

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

您确实需要分开两个问题:

1) 主键是一个逻辑结构 - 唯一且可靠地标识表中每一行的候选键之一。这实际上可以是任何东西 - INT、GUID、字符串 - 选择最适合您的场景的内容。

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

默认情况下，SQL Server 表上的主键也用作聚簇键 - 但不必如此!我个人看到，将以前基于 GUID 的主键/聚集键分解为两个单独的键 - GUID 上的主(逻辑)键和单独的 INT IDENTITY(1, 1)专栏。

如Kimberly Tripp - 索引女王 - 和其他人已经说过很多次 - GUID 作为集群键并不是最佳的，因为由于它的随机性，它将导致大量页面和索引碎片以及通常较差的性能。

是的，我知道 - SQL Server 2005 及更高版本中有 newsequentialid() - 但即便如此，它也不是真正完全顺序的，因此也会遇到与 GUID 相同的问题 - 只是有一点点不太明显。如果您坚持使用 GUID，那么至少在服务器上使用 newsequentialid() 方法!

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

快速计算 - 使用 INT 与 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 索引福音。

• 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!

马克