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

Question

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

我遇到过各种机制，用于将UUID存储在MySQL数据库中，但没有任何机制可以将它们相互比较。这些包括存储为：

• BINARY（16）
• CHAR（16）
• CHAR（36）
• VARCHAR（36）
• 2 x BIGINT

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

• 存储空间大小？
• 查询开销？ （索引问题，加入等）。
• 是否可以轻松插入和更新客户端代码中的值？ （通常是JP通过JPA）

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

Answer 1

如果你真的开始使用UUID，我会将它存储在二进制（16）列中。像2x bigint这样的东西管理起来会非常麻烦。另外，我听说有人倒车，因为同一台机器上UUID的启动在开始时往往是相同的，而且不同的部分都在最后，所以如果你反转它们，你的索引会更有效率。

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

Answer 2

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