什么是 UUID？何时应该使用 UUID？
打开几乎所有数据库、API 或应用，您都会发现类似 550e8400-e29b-41d4-a716-446655440000 的长字符串。这些是 UUID，它们解决了一个看似棘手的问题：如何在没有中央机构协调的情况下生成唯一标识符？以下是它们的工作原理以及何时使用它们。
什么是 UUID
UUID 代表通用唯一标识符 — 一个 128 位值，通常显示为 5 个连字符分隔的组中的 32 个十六进制字符。要点就在名称中：它被设计为在空间和时间上都是唯一的，因此任何地方的两个系统都可以独立生成 UUID 并且永远不会发生冲突。
不协调怎么能独特？
最常见的类型，版本 4，几乎完全是随机的 — 122 个随机位。可能值的数量如此之大（大约 5 十亿），以至于两个随机生成的 UUID 匹配的机会实际上为零，即使在数十亿个 UUID 中也是如此。您不需要中央柜台；仅凭随机性就几乎不可能发生碰撞。使用我们的 UUID 生成器立即生成一个。
UUID 与自动递增 ID
传统数据库使用顺序 ID（1、2、3…）。它们简单而紧凑，但也有 UUID 需要避免的缺点：
- 无需协调：多个服务器可以离线创建记录并稍后合并，而不会出现 ID 冲突。
- 不可猜测：连续 ID 会泄露信息（竞争对手可以看到您有“订单 #1043”）并且易于枚举； UUID 则不然。
- 随处生成：客户端可以在与服务器通信之前创建 ID。
何时使用哪个
将 UUID 用于分布式系统、面向公众的标识符、合并多个来源的数据或任何您不希望 ID 被猜测的地方。当您拥有单个数据库、需要紧凑键并重视人类可读的 ID 时，请坚持使用自动递增整数。许多系统同时使用内部整数密钥和外部 UUID。
关于权衡的说明
UUID 大于整数（16 字节与 4-8 字节），这会稍微影响大规模的存储和索引性能。对于大多数应用程序来说，差异可以忽略不计，而且好处多多，但值得了解。
您实际会遇到的 UUID 版本
并非所有 UUID 都是随机的。 版本 4（随机）是迄今为止最常见的版本，也是大多数“生成 UUID”工具所生成的版本。 版本 1 嵌入了时间戳和机器标识符，这使其可排序，但可能会泄漏信息。较新的版本 7 是按时间排序的和随机的 - 越来越受欢迎，因为它按时间顺序排序，同时保持不可猜测，这有助于数据库性能。对于大多数需求，v4 是安全的默认值；当您需要数据库友好的排序时，请使用 v7。
UUID 和数据库性能
一个真正的权衡：随机 v4 UUID 作为主键可能会损害数据库写入性能，因为每个插入都会落在索引中的随机位置，而不是像顺序整数一样整齐地附加在末尾。对于小规模来说，这是无关紧要的，但对于数百万行来说，这很重要——这正是时间排序的 v7 UUID 存在的原因。常见的模式是用于提高性能的内部自动递增键以及用于面向公众的 ID 的外部 UUID。
可能发生碰撞吗？
实际上，没有。随机 v4 UUID 的数量如此之大 (2^2^)，以至于您可以在数年内每秒生成数十亿个 UUID，并且永远不会发生冲突 - 概率相当于被陨石击中。正常使用时不需要检查重复项。无需任何中央协调即可实现防碰撞，这就是 UUID 在分布式系统中如此有用的全部原因。
底线
UUID 是一个 128 位标识符，其唯一性足以在任何地方生成而无需协调。当您需要分布式、不可猜测或客户端生成的 ID 时，可以使用它们；当您拥有一个数据库并且需要紧凑、可读的键时，请保留简单的整数。如需更多方便的开发实用程序，请参阅我们的开发人员工具包。
