3

我计划使用客户端提供的 UUID 作为 MySQL 数据库中多个表的主键。

我遇到了将 UUID 存储在 MySQL 数据库中的各种机制，但没有什么可以将它们相互比较。这些包括存储：

  • 二进制(16)
  • 字符(16)
  • 字符(36)
  • VARCHAR(36)
  • 2 x 大整数

有没有更好的选择，这些选项在以下方面如何相互比较：

  • 存储大小？
  • 查询开销？（索引问题、连接等）
  • 从客户端代码插入和更新值是否容易？（通常是通过 JPA 的 Java）

根据您运行的 MySQL 版本或存储引擎是否有任何差异？我们目前正在运行 5.1，并计划使用 InnoDB。我欢迎任何基于尝试使用 UUID 的实践经验的评论。谢谢。

4

2 回答 2

3

如果您确实设置了使用 UUID，我会将其存储在 Binary(16) 列中。像 2x bigint 这样的东西管理起来会很麻烦。另外，我听说有人反转它们，因为同一台机器上的 UUID 的开头往往一开始是相同的，而不同的部分在最后，所以如果你反转它们，你的索引会更有效率.

当然，我的直觉告诉你应该使用自动递增整数，除非你有充分的理由使用 UUID。一个很好的理由是在不同的数据库中生成唯一的密钥。另一种选择是您计划拥有比 INT 可以存储的更多的记录。虽然没有多少应用程序真正需要这样的东西。不使用整数作为键不仅会损失很多效率，而且使用它们也更加困难。它们太长而无法输入，并且在您的 URL 中传递它们会使 URL 非常长。因此，如果需要，请使用 UUID，但请尽量远离。

于 2009-09-01T16:38:14.440 回答
1

我已经将 UUID 用于智能客户端在线/离线存储和数据同步以及我知道在某些时候必须合并的数据库。我一直使用 char(36) 或 char(32)（没有破折号）。与 varchar 相比，您可以获得轻微的性能提升，并且几乎所有数据库都支持 char。我从未尝试过二进制或 bigint。需要注意的一件事是，如果您不使用 36 或 32 个字符，char 将用空格填充。重点是，不要编写将对象的 ID 设置为“测试”的单元测试，然后尝试在数据库中找到它。;)

于 2009-09-01T16:54:13.830 回答