asp.net-membership - 为什么主键是由 aspnet_regsql GUID 生成的？

Question

我正在 Visual Studio 2010 中开发 ASP.NET 网站(使用 Service Pack 1，非常感谢)。我想为 SQL Server 2008 使用 .NET 的内置成员身份和角色提供程序。

现在，我已经开发 Microsoft 技术很长时间了，并且与业内一些最优秀的 SQL Server DBA 擦肩而过。他们每个人都告诉我在构建数据库表时远离 GUIDS 作为主键:

拥有非常高的记录数。

有大量的插入和删除。

原因:因为主键是聚集索引!

这基本上意味着插入表中的每条记录都必须遵守索引的约束。因此，如果索引按 ASC 排序，则具有新生成的 GUID 的记录必须以适当的顺序物理楔入相关数据表中。

这对于只有几千条记录的表来说很好。 SQL Server 只需要重新定位少数几个。但是，如果数据表有几百万条记录，并且发现它必须在第 216 行插入新记录。这可能需要大量时间(根据 Web 标准)才能完成。它必须物理向下移动所有这些行，以插入新的行。

所以我的问题很简单。自从 Microsoft 以及我们所了解和喜爱的所有 DBS 都拒绝将 GUID 作为主键......为什么 ASPNET_REGSQL 工具使用 GUID 作为主键创建表？

或者我错过了什么？ 2008 年 SQL Profiler 引擎是否有一项新功能不再将 GUIDS 视为一项任务？

Answer 1

向导确实有一些优势；例如，如果您在应用程序代码中生成 guid，它们可以在 web 场中生成，而不必担心以相同的 ID 结束。另一个好处是可以锁定数据库中的页面而不会引起任何问题，因为在同一数据页面中不太可能存在两个随机选择的行。

至于你所说的几百万行数据 - 只要你总是要求 SQL 服务器返回单行数据，Guids 就可以了。最大的问题将是当您请求数据的一些大子集或批量插入大量行时；然后，您可能会执行大量随机 I/O 来获取符合您的条件的所有行，或者将所有行插入 guid 最终指向的随机位置。此外，SQL 不必“物理地将所有这些行向下移动以插入新行”；数据存储在页面上，SQL 通常只需要更改数据文件中一页上的数据即可插入行，可能还会更新其他几个页面，但这不像将行插入到大量文本文件中。

所有这些都说 - 是的，我通常也更喜欢主键的整数，但只是想指出在某些情况下 guid 确实有意义。