GUID + 自增ID = 性能变慢？

Question

Jeff Atwood认为使用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，自动递增作为非唯一索引吗？将它们作为一对唯一键更好吗？

感谢您的时间。

- yurisich

Answer 1

索引一个 int 是便宜且有用的。索引一个 GUID 是昂贵的（并且从面向Web的角度来看是安全的；没有人能够循环遍历 GUID 来请求表中的单个行）。SEQ GUID 提供了相对较快的索引构建，但消除了大部分可以为公共访问提供一些安全性的“随机性”。

根据 SQL Authority 上的讨论，从 int -> bigint -> guid 的最终进展是罕见的，并且在时机未到之前不应考虑。迄今为止，启动新项目的最安全和最可访问的方法是使用 bigint PK AUTO_INCR，其中 GUID 作为非索引、非顺序字段，专门用于在数据库的整个生命周期内进行分片或合并 shechmas。它在速度方面会受到前期的影响，但这些影响直到您拥有足够的行才真正关心跨实例唯一性等问题时才会感受到。

- yurisich

Answer 2

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

例如，您可以使用20位随机数字作为主键，并仅使用该数字：无需GUID！

- fge