在MYSQL表中存储UUID的各种选项及其权衡是什么？

Question

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

我遇到过将UUID存储在MySQL数据库中的各种机制，但没有任何机制将它们进行比较。其中包括储存如下：

• BINARY(16)
• CHAR(16)
• CHAR(36)
• VARCHAR(36)
• 2 x BIGINT

是否有更好的选择，这些选项如何在以下方面进行比较：

• 存储大小？
• 查询开销？(索引问题、联接等)
• 容易从客户端代码插入和更新值吗？(通常通过JPA进行Java )

基于您正在运行的MySQL的哪个版本或存储引擎有什么不同吗？我们目前正在运行5.1，并计划使用InnoDB。我欢迎任何基于尝试使用UUID的实际经验的评论。谢谢。

Answer 1

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

Answer 2

如果您确实打算使用UUID，我会将其存储在二进制(16)列中。像2x bigint这样的东西管理起来会很麻烦。而且，我也听说过有人将它们反转，因为在同一台机器上UUID的启动在开始时是相同的，不同的部分在末尾，所以如果您反转它们，您的索引就会更有效率。

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