我目前正在开发一个项目，需要使用SQL Azure数据库来存储即将到来的应用程序的数据。 该项目的目标之一是能够利用SQL Azure中的Federations（分片）。 该项目的另一个明确目标是，如果客户选择此方案，则能够在本地硬件上运行此应用程序。
我遇到的一个“障碍”是联盟中缺乏对IDENTITY的支持。
虽然我理解为什么 IDENTITY在Azure中不受支持，但我似乎有一种心理障碍，即接受使用GUID作为聚簇索引是一个好主意。
Clustered and nonclustered indexes performance
我已在上面的第一个链接中执行了示例测试，并确认在将记录插入到具有guid作为聚簇索引的表中而不是将相同数量的记录插入到表中时，Azure上的性能几乎没有差别。具有作为聚簇索引的int标识字段的表。
但是，由于我还需要支持内部部署安装，我认为当使用guids作为聚簇索引而不是使用int identity时，本地性能会受到影响是一个安全的声明。
除了与性能相关的问题之外，我还担心使用16字节宽的guid作为聚簇索引而使用4字节宽的整数作为聚簇索引。当然，磁盘空间相对便宜，但这仍然相当快（并且可能不必要）。
我意识到我最终必须在需要支持这些既定项目目标的基础上进行权衡，但我希望做出最明智的决定。
除了使用中间层id生成器之外，还有哪些替代方法可以在Azure上使用Guid作为聚簇索引（和/或主键），同时仍然使用联盟？
或者，我是否担心使用Guid作为聚集索引的基础（我承认它们非常好）？如果是这样，为什么？
答案 0 :(得分：0)
你是正确的打扰16字节Guid与4字节Int（我也这样做）。然而，采取光明的一面 - 联盟使您能够大规模扩展数据库层。
现在问题 - 根据Online Documentation，联邦分配类型只能是以下之一：
INT，BIGINT，UNIQUEIDENTIFIER或VARBINARY（n），其中n可以是 最多900
因此，我认为UNIQUEIDENTITIFIER是您应用的唯一选择。
在应用程序级别拥有任何类型的id生成器会引入单点故障/单点“崩溃”或瓶颈，这显然是SQL Azure Federations试图覆盖的。所以我不会使用任何ID生成逻辑，而是使用应用程序端的Guid.NewGuid（）或数据库端的NEWID（）。
至于UNIQUEIDENTIFIER对内部部署解决方案的性能影响，我不能说，这是一个单独的问题。
答案 1 :(得分：0)
显然，将SQLID与SQL Azure一起使用不会导致SQL Server安装的内部部署性能问题。
很多人都有建议GUID（uniqueidentifiers）的经验 因为它们不会被订购，所以它们是群集密钥的不良候选者 并导致页面拆分，导致更高的延迟和碎片？没有 所以在SQL Azure上
所以我可能会选择Guid的