当主键无法使用时，聚簇索引的最佳选择是什么？

给定一个应用程序，其中大多数表的主键是uuid，那么这些表上的聚集索引的最佳选择是什么？当主键无法使用时，聚簇索引的最佳选择是什么？

聚簇索引是必需的，因为后端数据库是Azure SQL Server，而Azure需要聚簇索引。
uuid是一种设计选择，可满足n个客户端在断开状态下创建实体并在连接时进行同步的需要。
我们不使用主键作为聚簇索引以避免由于uuids的随机性而导致的碎片问题。

考虑到以下数据类型：

int或bigint。简单 - 可以自动递增（好/坏），但似乎很随意，并且实用性有限。感觉最像一个黑客。
datetime - 增加的实用程序 - 可能是createdOnServer列。但会导致一些愚蠢的，因此需要uniqueness（这是多大的一个问题，我不知道）
datetime2 - 比datetime更宽，但更高的精度和更少的欺骗。

寻找哪些是最好的，需要考虑的事项或其他想法的评论。

来源

2016-02-04 user1843640

如有疑问，请记住KISS。采用简单的解决方案。 –

我不想告诉你 - 客户没有这个要求。例如：有些开发人员不够聪明，可以将数据库侧主键与基于仿真GUID的行标识分开。您没有理由将GUID作为数据库端主键。 – TomTom

我不知道你为什么解散自动递增int。任何被广泛使用的东西，工作得很好，只要你没有计划将表格（通过联盟）与其他版本的表格合并，为什么你不想使用它？它将提供一个非常好的关键（不是太宽），这是一个平衡的B树，聚簇索引在幕后。请记住，在具有聚集索引的表中，所有其他索引都将使用聚簇索引列来获取所需的页面和行，以便尽可能小。

来源

2016-02-04 18:36:29

我并没有放弃它，我正在考虑它。这就是它在问题中列出的原因。我只是不知道是否使用不同的数据类型更有意义。我已经有了一个主键，所以这个列只能用作聚集索引，而不能直接用在任何查询中。 – user1843640

如果您不想创建索引，可以考虑升级/移动到V12 Azure SQL数据库。这些不需要聚集索引。

在索引本身上：您应该在查询的列上创建它。例如，如果您对UUID +日期进行查找，则应在两者上创建索引以支持您的查询。

来源

2016-02-08 17:29:43

当主键无法使用时，聚簇索引的最佳选择是什么？

回答

相关问题