我已经阅读了几篇关于在 MySQL 中使用 UUID 作为主键的性能的在线文章——以及一个共同的主题，无论它们是支持还是反对，都是非顺序数据会损害索引性能的想法。
https://blog.codinghorror.com/primary-keys-ids-versus-guids/
生成的 GUID 应部分连续以获得最佳性能
https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
创建函数来重新排列 UUID 字段并使用它（在展示如何重新排列 UUID 可以显着提高性能之后）
但是，我根本无法理解非顺序数据如何影响 B-TREES、HASHES、CLUSTERED 索引等索引。
您可以将我的 UUID 博客添加到您的列表中。（它同样适用于 MySQL。）
请注意，直到索引（无论是集群，还是 BTree、散列或其他）太大而无法缓存在 RAM 中，才会出现性能问题。此时，您访问（或尝试插入）的“下一个”UUID 不太可能在 RAM 中，因此需要 I/O，这会影响性能。
相反，插入以日期时间为键的行，并且在某种程度上按时间顺序进行，将主要插入到 BTree 的同一块中。这意味着“下一个”行不太可能需要 I/O。
I/O 是影响性能的最大因素。
我的博客指出如何将1类 uuid 转换为类似于时间戳的东西，从而实现“引用的局部性”，从而减少 I/O，从而提高速度。MySQL 8.0 具有与我的存储函数执行相同操作的内置函数。不过，您需要 Type 1并需要调用该函数，以减少 I/O。