是否有不会导致数据库性能问题的 UUID / GUID 的替代品？答案

【问题标题】：Is there an alternative to UUIDs / GUIDs that doesn't cause database performance issues?是否有不会导致数据库性能问题的 UUID / GUID 的替代品？
【发布时间】：2018-11-01 15:46:07
【问题描述】：

如here 所述，在关系数据库上下文中使用 UUID / GUID 是个坏主意。有没有支持库的替代方案？

【问题讨论】：

“这个博客在 MySQL 8.0 中大部分被删除了”——直接来自那个链接。
@mxmissile 是的，但它很好地说明了这个问题，也许我没有使用 MySQL 8。即使我是，我仍然需要注意如何存储 UUID 并使用正确的函数.我预计许多应用程序设计人员会忘记这样做并使用 varchar(36)...

标签： uuid guid

【解决方案1】：

不是一篇很棒的博文。 GUID 在客户端需要生成自己的主键的情况下非常有用。如果服务器可以生成密钥，请使用自增整数主键。

让我详细说明为什么这不是一篇很棒的博文。他说：

GUID/UUID 非常随机。因此，插入索引意味着跳来跳去。

Guid 实际上只是一个 16 字节的十六进制数；所以我可以想出一个简单的索引，只需制作一个可以逐位遍历的 32/16 数组，就可以在恒定时间内完成一次插入。因此，可以在 Log(N) 时间内使用我的幼稚索引插入 N 个项目。博客文章中的论点很糟糕。我不确定 GUID 插入速度是否很快，但“随机性”与算法复杂性无关。

这是一篇不错的博客文章，其中包含一些不错的链接：

https://blog.codinghorror.com/primary-keys-ids-versus-guids/

我特别喜欢这个链接：

http://web.archive.org/web/20150511162734/http://databases.aspfaq.com/database/what-should-i-choose-for-my-primary-key.html

很好地讨论了不同键的权衡。

【讨论】：

我希望对存储在企业中的所有实体使用这种格式，这可能是数十亿行，每个都有多个版本。所以是的，性能很重要，否则 UUID 格式会很好。我希望多个服务器进程生成不会在整个范围内发生冲突的 id。