非顺序（例如，UUID/GUID）数据如何降低索引性能？

Question

我读过几篇关于在 MySQL 中使用 UUID 作为主键的性能的在线文章 - 无论它们是赞成还是反对，一个共同的主题是非顺序数据会损害索引性能。

生成的 GUID 应部分连续以获得最佳性能

创建函数来重新排列 UUID 字段并使用它（在展示重新排列 UUID 如何显着提高性能之后）

但是，我根本无法理解非顺序数据如何影响 B-TREES、HASHES、CLUSTERED 索引等索引。

Answer 1

您可以将我的 UUID 博客添加到您的列表中。（它同样适用于 MySQL。）

请注意，直到索引（无论是聚簇索引，还是 BTree、散列索引或其他索引）太大而无法在 RAM 中缓存时，才会出现性能问题。此时，您获取（或尝试插入）的“下一个”UUID 不太可能位于 RAM 中，因此需要 I/O，这会影响性能。

相比之下，插入以日期时间为键的行，并且按时间顺序进行，主要是插入到 BTree 的同一块中。这意味着“下一个”行不太可能需要 I/O。

I/O 是性能的最大因素。

我的博客指出了如何将Type 1 uuid 转换为类似于时间戳的东西，从而实现“引用局部性”，从而减少 I/O，从而提高速度。MySQL 8.0 具有与我的存储函数执行相同操作的内置函数。尽管如此，您仍然需要类型 1并需要调用该函数，以减少 I/O。