聊聊用 UUID/GUID 作为主键那些坑

访问欠友好的 UUID

我刚读了一篇有关如何扩展数据库的文章，作者建议将 UUID（类似于 GUID）用作数据库表的主键（PK）。

使用 UUID 的优点

与自动递增整数相比，将 UUID 用作主键的优点很多：

• 适合大规模数据。当你把数据分片（例如一组客户数据）存在多个数据库时，使用 UUID 意味着 ID 在所有数据分片中都是唯一，而不仅仅是当前那个分片所在数据库。这使得跨数据库移动更为安全。在我的环境，所有数据库分片都可以简单合并到 Hadoop 集群中，不会有主键冲突的问题。

• 在插入数据之前就可以知道 PK，这避免了查询 DB 开销，并简化了事务逻辑，比如在使用该键作为其它表外键（FK）时，需要预先获得这个 PK

• UUID 不会泄露数据信息，因此在 URL中暴露会更安全。如果一个用户 ID 是 12345678，很容易猜到还有用户 12345677 和 1234569，这构成了攻击因素。（请参见下面的更好的选择）。

使用 UUID 的缺点

不直观

很多人直接使用 UUID （类似像70E2E8DE-500E-4630-B3CB-166131D35C21 ）作为字符串，例如 varchar(36) — 请不要这样做！

你可能会说没有人会这么干。

这个问题请三思 — 我曾接手过某些大公司中两个非常大的数据库案例，这恰恰是现实。除了 9 倍大小的开销（int 的大小为 4 字节），字符串的排序速度也不如数值型字段快，因为它们依赖于排序规则。

在一家最初决定使用 Latin-1 字符集的公司中，情况就更麻烦。当我们需要将字符集转换为 UTF-8 时，几个复合键索引就存不下更改后的字符串。

UUID 的痛苦

不要低估字段太长无法口头表达及记住的痛苦。

规划扩展计划

如果我们的目标是扩展&