GUID + 自动增量 ID = 性能缓慢？答案

【问题标题】：GUID + Auto-Increment ID = Slow Performance?GUID + 自动增量 ID = 性能缓慢？
【发布时间】：2011-12-16 16:41:54
【问题描述】：

Jeff Atwood's 使用 GUID 的一个缺点是它是

Cumbersome to debug (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')

我同意。我在想，既然 16 字节 ID 不再被认为是一项艰巨的任务，那么 16 字节 + 4 字节 ID 是不是一个实际的折衷方案？

您可以应用聚集索引，并在自动增量 ID 上进行大部分串行（阅读：优化）工作。合并、分发或其他大规模活动将使用 GUID 作为其主要工作。

那么...有人尝试混合两全其美吗？你的事业的结果是什么？当然，存在一个 PK（GUID）在另一个索引字段（自动增量 ID）旁边占用所有索引空间的问题，所以我想这种权衡可能是微妙的和/或特定于一个非常狭窄的场景.

注意：this question 之前已经解决了这个问题，但从管理参照完整性的角度来看。我只是好奇如何将 PK/UK 配置组合在一张桌子上，以及它们对性能和规模的各种影响。本质上，最好将 GUID 用作 PK，并将自动增量用作非唯一索引？将它们作为一对唯一的密钥会更好吗？

感谢您的宝贵时间。

【问题讨论】：

标签： performance database-design primary-key guid unique-key

【解决方案1】：

索引int 既便宜又有用。索引GUID 是昂贵的（并且从面向网络的前端安全；没有人能够循环通过GUIDs 从表中请求单个行）。 SEQ GUIDs 在大量插入后确实提供了（相对）快速的索引构建，但消除了大部分可以为公共访问提供一些安全性的“随机性”。

从这个discussion on SQL Authority 开始，从int -> bigint -> guid 的最终进展是罕见的，在时间需要之前不应考虑。到目前为止，开始一个新项目的最安全和最容易访问的方法是使用bigint PK AUTO_INCR，将GUID 作为非索引、非顺序字段，专门用于在数据库的整个生命周期中分片或合并shechma。就速度而言，它需要预先受到影响，但在您有足够的行来真正关心诸如跨实例唯一性之类的事情之前，不会感受到这些影响。

【讨论】：

【解决方案2】：

自动增量 ID 的问题在于插入性能：如果您插入数千行，这意味着在数据库级别有数千个自动增量。另一方面，索引插入不是问题，散列方法确保了总体上良好的分布。

例如，您可以使用 20 位的随机数作为主键并仅使用它：不需要 GUID！

【讨论】：