在 SQL Azure（联合）中使用 guid 作为表上的聚集索引有哪些替代方法

Question

我目前正在开展一个项目，该项目需要使用 SQL Azure 数据库来存储即将推出的应用程序的数据。 该项目的目标之一是能够利用 SQL Azure 中的联合（分片）。 该项目的另一个既定目标是，如果客户选择此方案，则能够在本地硬件上运行此应用程序。

我面临的“障碍”之一是联邦缺乏对 IDENTITY 的支持。

http://blogs.msdn.com/b/cbiyikoglu/archive/2011/06/20/id-generation-in-federations-identity-sequences-and-guids-uniqueidentifier.aspx

虽然我了解为什么 IDENTITY 在 Azure 中不受支持，但我似乎有一个心理障碍，即接受使用 GUID 作为聚集索引是一个好主意。

Clustered and nonclustered indexes performance

我已经执行了上面第一个链接中的示例测试，并确认在 Azure 上将记录插入到具有 guid 作为聚集索引的表中与将相同数量的记录插入到具有用作聚集索引的 int 标识字段的表。

但是，由于我还需要支持本地安装，我认为可以肯定地说，当使用 guid 作为聚集索引而不是使用 int 标识时，本地性能会受到影响。

除了与性能相关的问题外，我还担心使用 16 字节宽的 guid 作为聚集索引与使用 4 字节宽的整数作为聚集索引。当然，磁盘空间相对便宜，但这仍然会很快增加（而且可能是不必要的）。

我意识到我最终将不得不根据需要支持这两个既定的项目目标做出权衡，但我希望做出我能做出的最明智的决定。

除了使用中间层 id 生成器之外，还有哪些替代方法可以在 Azure 上使用 Guid 作为聚集索引（和 \ 或主键）同时仍使用联合？

另外，我是否担心使用 Guid 作为离基的聚集索引（我承认他们很可能是这样）？如果有，为什么？

Answer 1

您对 16 字节 Guid 与 4 字节 Int 的争论是对的（我也这样做）。但是有好的一面 - 联邦让您能够大规模扩展 DB 层。

现在的问题 - 根据Online Documentation，Federation Distribution 类型只能是以下之一：

INT、BIGINT、UNIQUEIDENTIFIER 或 VARBINARY(n)，其中 n 可以是 最多 900

所以我认为 UNIQUEIDENTITIFIER 确实是您应用的唯一选择。

在应用程序级别使用任何类型的 id 生成器都会引入单点故障/单点“崩溃”或瓶颈，这显然是 SQL Azure Federations 试图解决的问题。所以我不会使用任何 ID 生成逻辑，而不是应用程序端的 Guid.NewGuid() 或数据库端的 NEWID()。

至于 UNIQUEIDENTIFIER 对本地解决方案的性能影响，我不能说，这是一个单独的问题。

Answer 2

显然，在 SQL Azure 中使用 GUID 不会产生与本地 SQL Server 安装相同的性能问题。

很多人都有建议 GUID（唯一标识符）的经验 由于它们不会被排序，因此它们是聚类键的不良候选者 并导致页面拆分，导致更高的延迟和碎片？不 等等 SQL Azure

http://blogs.msdn.com/b/cbiyikoglu/archive/2012/05/17/id-generation-in-federations-identity-sequences-and-guids-uniqueidentifier.aspx

所以我可能会选择 Guid 的