不能使用主键时，聚集索引的最佳选择是什么？答案

【问题标题】：What is the best choice for clustered index when the primary key can't be used?不能使用主键时，聚集索引的最佳选择是什么？
【发布时间】：2016-02-09 01:29:43
【问题描述】：

对于大多数表的主键是 uuid 的应用程序，这些表上的聚集索引的最佳选择是什么？

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

考虑以下数据类型：

int 或 bigint。容易 - 可以自动递增（好/坏），但看起来如此随意且实用性有限。感觉最像黑客。
datetime - 增加的实用性 - 可以是 createdOnServer 列。但会导致一些欺骗，因此需要唯一符（这是一个多大的问题，我不知道）
datetime2 - 比 datetime 更宽，但精度更高，欺骗更少。

寻找最佳的 cmets、要考虑的事情或替代想法。

【问题讨论】：

如有疑问，请记住 KISS。选择简单的解决方案。
我不想告诉你——客户没有这个要求。如：一些开发人员不够聪明，无法将数据库端主键与基于 GUID 的人工行标识分开。你没有理由让 GUID 成为数据库端的主键。

标签： sql-server azure azure-sql-database

【解决方案1】：

我不确定你为什么不考虑自动递增 int。任何被广泛使用的东西都可以很好地工作，只要您不打算将表格（通过联合）与表格的其他版本合并，您为什么不想使用它？它将为聚集索引位于幕后的平衡 B 树提供一个非常好的键（不太宽）。请记住，在具有聚集索引的表中，所有其他索引都将使用聚集索引列到达所需的页面和行，因此您希望使其尽可能小。

【讨论】：

我不会拒绝它，我正在考虑它。这就是为什么它在问题中列出。我只是不知道使用不同的数据类型是否更有意义。我已经有一个主键，所以这个列只能用作聚集索引，而不是直接用于任何查询。

【解决方案2】：

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

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

【讨论】：