插入 UUID 主键索引的性能答案

【问题标题】：Inserting performance for UUID primary_key index插入 UUID 主键索引的性能
【发布时间】：2019-12-22 06:59:06
【问题描述】：

我读到 UUID 作为主键的插入性能取决于数据库中存在多少条记录。记录数越多，插入记录的时间就越长

上述文章的作者进行了实验，他认为这是因为 UUID 主键插入的读取次数比其他自增整数要多。

我想问一下数据库是否会自动为所选的 primary_key 创建索引如果 UUID 主键索引是问题，插入问题是否可以通过使用整数作为主键索引同时仍然保留 UUID 字段来解决，然后将主键切换为 UUID，那么问题是外键引用整数 ID切换时传播到 UUID 字段？

【问题讨论】：

【解决方案1】：

数据库是否自动为所选的primary_key创建索引

是的。主键始终被索引。在某些数据库中，索引是聚集索引（意味着数据页上的数据实际上是按键排序的）。在其他数据库中，索引是为了强制唯一性约束。

UUID 和索引的问题在于新值不一定比旧值大。这意味着插入通常“在”两个现有记录之间进行。当这种情况发生时，您就会产生碎片——也就是说，现有数据页需要为新记录腾出空间，有时甚至会分成两页。

自动递增的整数没有这个问题。它被索引（并在 MySQL 中聚集）。但是，较新的值比任何现有值都大——自动递增的定义。所以，新的价值观在最后。只有在删除行或手动设置值时，碎片才会成为问题。

我建议您使用自动递增的主键，除非您对 UUID 有特定原因。

【讨论】：