使用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，将自动增量用作非唯一索引吗？将它们作为一对独特的钥匙更好吗？
感谢您的时间。
答案 0 :(得分：2)
索引int既便宜又有用。索引GUID是昂贵的（并且从面向Web的前端安全;没有人能够循环通过GUID来从表中请求单个行。 SEQ GUID确实在大量插入后提供（相对）快速索引构建，但消除了大多数可以为公共访问提供安全性的“随机性”。
从此discussion on SQL Authority开始，int - ＆gt;的最终进展bigint - ＆gt; guid是一种罕见的，在需要时才应予以考虑。到目前为止，用于启动新项目的最安全且最易于访问的方法是使用bigint PK AUTO_INCR，GUID作为非索引的非连续字段，专门用于在整个生命中分割或合并shechmas的数据库。它在速度方面需要预先考虑，但是只有在有足够的行来实际关注跨实例唯一性之类的事情之后才能感受到这些影响。
答案 1 :(得分：0)
自动增量ID的问题是插入性能：如果插入数千行，则表示数据库级别有数千个自动增量。另一方面，索引插入不是问题，散列方法确保了通常良好的分布。
例如，您可以使用20位数的随机数作为主键，并仅使用它：不需要GUID！