MySQL 主键 : UUID/GUID vs BIGINT (timestamp+random)

Question

tl;dr:如果我不想处理 UUID，将 {unixtimestamp}{randomdigits} 的行 ID(例如 1308022796123456)分配为 BIGINT 是个好主意吗？

只是想知道是否有人对分配给跨多个服务器的数据库记录的 ID/PRIMARY KEY 的任何性能或其他技术考虑/限制有一些了解。

我的PHP+MySQL应用运行在多台服务器上，需要数据能够合并。所以我已经不再使用标准的顺序/自动增量整数方法来识别行。

我对解决方案的研究使我想到了使用 UUID/GUID 的概念。然而，需要更改我的代码以处理将 UUID 字符串转换为 MySQL 中的二进制值的问题似乎有点痛苦/工作。出于存储和性能原因，我不想将 UUID 存储为 VARCHAR。

存储在二进制列中的 UUID 的另一个可能令人烦恼的事实是，在 PhpMyAdmin 中查看数据时，行 ID 并不明显 - 虽然我对此可能是错误的 - 但总的来说，直接数字似乎要简单得多，而且无需转换即可在任何类型的数据库系统中通用。

作为折中方案，我想到了将我的 ID 列设为 BIGINT，并使用当前 unix 时间戳后跟 6 个随机数字来分配 ID。所以假设我的随机数是 123456，我今天生成的 ID 将显示为:1308022796123456

在同一秒内创建的行发生冲突的概率为千万分之一，这对我来说没问题。我不会快速创建任何类型的大量行。

我读到的关于随机生成的 UUID 的一个问题是它们对索引不利，因为值不是连续的(它们散布在各处)。 MySQL 中的 UUID() 函数通过从当前时间戳生成 UUID 的第一部分来解决这个问题。因此，我复制了在我的 BIGINT 开头使用 unix 时间戳的想法。我的索引会很慢吗？

我的 BIGINT 想法的优点:

• 给我 UUID 的多服务器/合并优势
• 只需对我的应用程序代码进行少量更改(一切都已编程为处理 ID 的整数)
• UUID 的一半存储空间(8 字节对 16 字节)

缺点:

• >？？？ - 如果您能想到，请告诉我。

与此相关的一些后续问题:

1. 我应该在末尾使用多于还是少于 6 个随机数字？它会对指数表现产生影响吗？

2. 这些方法之一是“随机”的吗？:让 PHP 生成 6 位数字并将它们连接在一起 -VS- 让 PHP 生成 1 - 999999 范围内的数字，然后进行零填充以确保 6 位数字。

感谢任何提示。对不起，文字墙。

Answer 1

我在职业生涯中遇到过这个问题。我们使用时间戳 + 随机数，当我们的应用程序扩展时(更多客户端、更多服务器、更多请求)遇到了严重的问题。诚然，我们(愚蠢地)只使用了 4 位数字，然后改为 6 位，但您会惊讶于错误仍然发生的频率。

在足够长的时间段内，您保证会遇到重复键错误。我们的应用程序是关键任务，因此即使是由于固有的随机行为而导致失败的可能性很小也是 Not Acceptable 。我们开始使用 UUID 来避免这个问题，并仔细管理它们的创建。

使用 UUID，您的索引大小会增加，索引越大，性能越差(可能不明显，但仍然更差)。然而，MySQL 支持 native UUID 类型(永远不要使用 varchar 作为主键!!)，即使与 bigint 相比，它也可以非常有效地处理索引、搜索等。对索引的最大性能影响几乎总是索引的行数，而不是被索引的项目的大小(除非你想在长文本或类似的荒谬的东西上建立索引)。

回答您的问题:如果您不打算显着扩展您的应用程序/服务，Bigint(附有随机数)就可以了。如果您的代码可以在不做太多改动的情况下处理更改，并且您的应用程序不会在发生重复键错误时崩溃，那就继续吧。否则，咬紧牙关，选择更实质性的选择。

你以后总是可以实现更大的改变，比如切换到一个完全不同的后端(我们现在正面临着......:P)