【问题标题】:Non-clustered GUID primary key OR clustered int primary key and GUID secondary key with unique index?非聚集 GUID 主键或聚集 int 主键和具有唯一索引的 GUID 辅助键?
【发布时间】:2014-07-30 23:25:30
【问题描述】:

这些替代方案的优缺点?

  1. 具有非聚集索引的非顺序 GUID 主键
  2. 具有带聚集索引的顺序整数主键和具有唯一索引的随机 GUID 作为辅助键

我将在 GUID 键上获取对象,但我想知道出于任何其他原因使用带有聚集索引的顺序主键是否有任何好处?

我当然可以使用顺序 GUID,然后同时拥有 GUID 和聚集索引,但抛开这个选项,还有什么更好的选择?

【问题讨论】:

    标签: sql-server primary-key clustered-index


    【解决方案1】:

    我认为如果您只使用您的 GUID 获取记录,那么您就不需要顺序整数主键。但是,如果您以任何其他方式查询表,那么我建议您将代理整数主键作为聚集索引。如果没有聚集索引,您的表将变成一个堆,SQL Server 将为每条记录添加一个行标识符,该行标识符可能大于您的代理键列。见这里:

    http://msdn.microsoft.com/en-us/library/hh213609.aspx

    如果可能的话,我还希望使用代理键而不是 GUID 来检索记录。

    【讨论】:

      【解决方案2】:

      优点是连接。我经常使用这种方法 - 一个非集群唯一 GUID 作为对象的标识符,一个 int / bigint it 字段作为主键,然后也用于连接。

      【讨论】:

        【解决方案3】:

        如果您在表上创建附加索引,这些索引将通过其主键值引用表数据。因此,如果您保持 PK 列较小,您将拥有优势。我的答案是创建一个小的 int (IDENTITY) 主键,聚集,并在 GUID 值上具有唯一的非聚集索引。

        【讨论】:

          猜你喜欢
          • 2015-03-12
          • 2016-05-22
          • 2018-08-04
          • 2010-12-17
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多