MySQL中UUID的性能表现？

Question

109

我们正在考虑使用UUID值作为MySQL数据库的主键。插入的数据由数十个，数百个甚至数千台远程计算机生成，并以每秒100-40,000次的速度插入，我们永远不会进行任何更新。

数据库本身通常会在开始清除数据之前达到约50M条记录，因此既不是庞大的数据库，也不是微小的数据库。我们还计划在InnoDB上运行，尽管如果有更好的引擎适合我们所做的事情，我们也可以改变这一点。

我们准备使用Java的Type 4 UUID，但在测试中发现了一些奇怪的行为。首先，我们存储为varchar（36），我现在意识到我们最好使用binary（16）-虽然我不确定会好多少。

更重要的问题是：当我们有5000万条记录时，这些随机数据会严重损坏索引吗？如果我们使用例如type-1 UUID，其中左侧位戳记，则是否更好？或者也许我们应该放弃UUID，考虑自动增量主键？

我正在寻找关于将不同类型的UUID存储为MySQL的索引/主键时性能的普遍想法/提示。谢谢！

- Patrick Lightbody

2

一个重要的细节缺失了：主键由日志服务器生成还是由客户端机器自己生成？ - user3850

1

希望它们是由插入数据的10-1000个客户端生成的。 - Patrick Lightbody

你的场景中需要通用唯一性的地方在哪里？我的建议是坚持使用auto_increment，并使用一个单独的字段来描述发送数据的远程计算机。这里没有必要重新发明轮子。 - Theodore Zographos

在UUIDs中性能陷阱的更多讨论。 - Rick James

https://dev59.com/7F0a5IYBdhLWcg3wVHTU#30462400 - Eugen Konkov

11个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Rick James · Answer 1

UUIDs 导致性能不佳的主要情况是...

当 INDEX 太大无法缓存在 buffer_pool 中时，每次查找往往会导致磁盘访问。对于 HDD，这可能会使访问速度减慢 10 倍或更多。（不，这不是 "10%" 的打字错误。）对于 SSD，减速较小，但仍然显著。

这适用于任何 "哈希"（MD5、SHA256 等），但有一个例外：重新排列其位的类型 1 UUID。

背景和手动优化：UUIDs

MySQL 8.0：参见 UUID_TO_BIN() 和 BIN_TO_UUID()

MariaDB 10.7 进一步使用其 UUID 数据类型。