GUID +自动增量ID =性能较差？

Question

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

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，并将自动增量用作非唯一索引？将它们作为一对独特的钥匙是否更好？

谢谢你的时间。

Answer 1

自动递增ID的问题是插入性能：如果插入数千行，则意味着在数据库级别有数千个自动递增。另一方面，索引插入不是一个问题，哈希方法确保了一个良好的分布。

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

Answer 2

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

从这个discussion on SQL Authority，从int最终进展 - >bigint - >​​是一种罕见的一个，直到它的时间要求不应该被考虑在内。到目前为止，用于启动一个新项目的最安全和最易于访问的方法是使用bigint PK AUTO_INCR，将GUID用作非索引的非顺序字段，专门用于在数据库整个生命周期中分片或合并分片。它在速度方面需要一定的投入，但直到有足够的行才能真正关注跨实例唯一性之类的事情时，才会感受到这些影响。