揭开谜底：MySQL 为何不推荐 UUID 作为主键

前言：数据库主键的奥秘

在数据库设计中，选择合适的主键对于确保数据完整性和查询效率至关重要。MySQL 作为最受欢迎的关系型数据库管理系统之一，对于主键的选择有着明确的建议。然而，与其他数据库系统不同，MySQL 官方强烈反对使用 UUID（通用唯一标识符）作为主键。

UUID 的局限性：性能瓶颈

UUID 是一种随机生成的 128 位数字，旨在创建唯一的标识符。虽然 UUID 对于需要在分布式系统中生成唯一标识符非常有用，但将其用作 MySQL 中的表主键却存在重大缺陷。

MySQL 使用 B 树索引来快速查找和检索数据。B 树索引依赖于主键的顺序性，这意味着连续自增的 ID 可以优化索引结构，从而提高查询性能。另一方面，UUID 是随机生成的，破坏了 B 树索引的顺序性，导致索引查找效率低下。

InnoDB 表的限制

MySQL 中最流行的存储引擎 InnoDB 也对 UUID 作为主键提出了限制。InnoDB 使用聚簇索引，这意味着数据按主键顺序物理存储在磁盘上。使用 UUID 作为主键会破坏这种聚簇，导致数据碎片和性能下降。

此外，InnoDB 还对主键大小有限制。UUID 是 128 位数字，远远超过了 InnoDB 允许的最大主键大小（64 位）。这可能导致存储和索引问题，进一步影响性能。

连续自增 ID 的优势

与 UUID 相比，MySQL 官方推荐使用连续自增的整数作为主键。连续自增 ID 提供了许多优势，包括：

• 更好的索引性能： 连续自增 ID 保持了 B 树索引的顺序性，从而优化了索引查找。
• 更快的插入： 连续自增 ID 可以通过主键预测预先分配空间，从而加快插入操作。
• 更小的存储空间： 连续自增 ID 比 UUID 更紧凑，需要更少的存储空间。
• 更简单的设计： 使用连续自增 ID 进行主键设计更简单、更直观。

替代方案：UUID 的替代选择

虽然 MySQL 不推荐 UUID 作为主键，但仍有其他方法可以在 MySQL 中生成唯一标识符：

• BINARY(16) ：此数据类型生成 16 字节的随机二进制字符串，类似于 UUID，但更适合用作 MySQL 中的主键。
• UUID 函数： MySQL 提供了一个 UUID 函数，用于生成 UUID。但是，生成的 UUID 不适合用作主键，因为它们是随机生成的，而不是连续的。

结论

虽然 UUID 作为唯一标识符非常有用，但将其用作 MySQL 中的表主键却存在重大缺陷。MySQL 官方强烈建议使用连续自增 ID，因为它们提供了更好的性能、更快的插入、更小的存储空间和更简单的设计。通过遵循这些建议，您可以优化 MySQL 数据库的性能并确保其可靠性。