被追着问UUID和自增ID做主键哪个好，为什么？

之前无意间看到群友讨论到用什么做主键比较好

其实 UUID 和自增主键 ID 是常用于数据库主键的两种方式，各自具有独特的优缺点。

UUID

UUID 是一个由 128 位组成的唯一标识符，通常以字符串形式表示。它可以通过不同的算法生成，例如基于时间戳的 UUID（version 1）和基于随机数的 UUID（version 4）等。

UUID 的优点

全局唯一性：通过不同算法生成，几乎能够保证在全球范围内的唯一性，从而避免了多台机器之间可能发生的主键冲突问题。
不可预测性：随机生成的 UUID 很难被猜测，因此在需要保密性的应用场景下非常适用。
分布式应用：由于可以在不同的机器上生成 UUID，因此可以被广泛应用于分布式系统中。

然而，UUID 作为主键 ID 也存在一些缺点：

存储空间较大：UUID 通常以字符串形式存储，占用的存储空间较大。
不适合范围查询：由于不是自增的，不支持范围查询。新生成的 UUID 可能会插入到已有数据的中间位置，导致范围查询时出现数据重复或漏数据的情况。
不方便展示：UUID 通常比较长，且没有明确的业务含义，因此不太适合在系统间或前台页面进行展示。
查询效率低下：
- 在 UUID 列上创建索引会导致索引大小增加，从而影响缓存命中率，增加磁盘 I/O 需求，同时也增加了查询时的内存开销。
- 当使用 UUID 进行排序时，新生成的 UUID 通常会插入到叶子节点的中间位置，导致 B+树的频繁分裂和平衡操作，进而影响查询性能。

自增 ID

在 MySQL 中，可以通过设置 AUTO_INCREMENT 属性实现 ID 的自增长，通常用于作为主键 ID。

使用自增 ID 作为主键的好处包括：

存储空间节省：ID 为数字，占用的位数比 UUID 小得多，因此在存储空间上更加节省。
查询效率高：ID 递增，利于 B+Tree 索引的查询效率提高。
方便展示：ID 较短，方便在系统间或前台页面进行展示。
分页方便：ID 连续自增，有利于解决深度分页问题。

然而，使用自增主键也存在一些问题：

分库分表困难：在分库分表时，无法依赖单一表的自增主键，可能导致冲突问题。
可预测性：由于 ID 是顺序自增的，因此具有一定可预测性，存在一定的安全风险。
可能用尽：自增 ID 可能是 int、bigint 等，但它们都有范围限制，可能会用尽。
性能问题：在数据迁移期间，如果使用自增主键，数据库可能会产生额外的性能开销。这可能是由于重新计算主键值或更新相关索引所致。这可能会导致数据迁移过程变慢。

到底什么是 UUID，它能保证唯一吗？

UUID（Universally Unique Identifier）是一种全局唯一标识符，用于在同一时空中的各台机器上保证唯一性。

UUID 的生成基于特定算法，通常使用随机数生成器或基于时间戳的方式。生成的 UUID 以 32 位 16 进制数表示，总共 128 位（标准 UUID 格式为：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx，共 32 个字符）。

由于 UUID 是由 MAC 地址、时间戳、随机数等信息生成的，因此具有极高的唯一性，几乎不可能重复。但在实际实现中，UUID 有多种版本，它们的唯一性指标也有所不同。

UUID 的具体实现版本包括基于时间的 UUID V1 和基于随机数的 UUID V4 等。

在 Java 中，java.util.UUID生成的 UUID 包括 V3 和 V4 两种版本。

UUID 的优缺点

UUID 的优点在于其性能较高，不依赖网络，可以在本地生成，并且使用起来相对简单。

然而，UUID 也存在两个明显的缺点：

长度过长：UUID 通常由 32 位 16 进制数字组成，因此长度较长。例如，对于类似"550e8400-e29b-41d4-a716-446655440000"的字符串，几乎没有任何程序员能够直观理解其含义。
缺乏含义：UUID 是随机生成的，因此缺乏任何业务或语义上的含义。一旦将其用作全局唯一标识，可能导致在日后的问题排查和开发调试过程中遇到较大困难。

各个版本实现

V1. 基于时间戳的 UUID

基于时间戳的 UUID 是通过计算当前时间戳、随机数和机器 MAC 地址得到的。由于算法中使用了 MAC 地址，这个版本的 UUID 能够确保在全球范围内的唯一性。然而，使用 MAC 地址也带来了安全性问题，因此这个版本的 UUID 受到了批评。如果应用只在局域网中使用，也可以使用一种简化的算法，以 IP 地址代替 MAC 地址。