面试速答（先看这里）

**一句话结论：**UUID 是一个 128 位长的唯一标识符，通常以字符串形式表示。

60秒标准回答：

UUID和自增主键ID是作为数据库主键比较常用的方式。使用这两个做主键各自都有优缺点

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

UUID当做主键ID的话的缺点同样也有，如

**答题顺序：**结论 → 原理/机制 → 关键流程 → 场景与取舍 → 易错点

回答主线：

**记忆锚点：**UUID → version → 大的索引 → laiyanhong-9tr5c → vt2c0u76821n4zu8 → AUTO_INCREMENT

关键取舍：

易错提醒：

全局唯一：使用不同的算法生成，几乎可以保证在全球范围内唯一，避免了多台机器之间主键冲突的问题。
但是，使用自增主键做主键ID也存在一定的问题：分库分表：当我们做分库分表的时候，就没办法依赖一张表的自增主键来做主键ID了，这样就会发生重复导致冲突的问题可预测：因为ID是顺序自增的，所以是可以预测的，这就给系统带来了一定的安全风险。

加分表达：

不可预测性：随机生成的 UUID 很难被猜测出来，对于需要保密性的应用场景较为适用。
（后插入的UUID在排序时可能比前面的要小，在做范围查询的时候可能会出现数据重复或者漏数据的情况）不方便展示：主键ID有的时候会需要在系统间、或者前台页面展示，如果是UUID的话，就因为比较长、并且没有任何业务含义，所以不方便展示。
在 MySQL 中，可以通过设置 AUTO_INCREMENT 属性实现ID的自增长，通常可以用来作为主键ID。

追问准备：

典型回答

UUID和自增主键ID是作为数据库主键比较常用的方式。使用这两个做主键各自都有优缺点。

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

他的优点是：

UUID当做主键ID的话的缺点同样也有，如：

存储空间比较大：UUID 通常以字符串形式存储，占用的存储空间比较大。
不适合范围查询：因为不是自增的，所以在做范围查询的时候是不支持的。（后插入的UUID在排序时可能比前面的要小，在做范围查询的时候可能会出现数据重复或者漏数据的情况）
不方便展示：主键ID有的时候会需要在系统间、或者前台页面展示，如果是UUID的话，就因为比较长、并且没有任何业务含义，所以不方便展示。
查询效率低：
在UUID列上创建索引，因为他很长，所以索引的大小会变得非常大。大的索引会占用更多的磁盘空间，导致缓存命中率下降，进而增加了磁盘I/O的需求。此外，大的索引还会导致查询时的内存开销增加。
当使用UUID进行排序时，新的UUID值通常会插入到叶子节点的中间位置。这可能导致B+树的分裂和平衡操作频繁进行，从而增加了写入的开销。每次分裂或平衡都涉及到数据的重新排序和移动，这会影响查询的性能。

> UUID v7这个版本中，已经可以实现自增的UUID了（https://www.yuque.com/laiyanhong-9tr5c/zwpzru/vt2c0u76821n4zu8 ），但是目前JDK官方并未支持，想要使用的话需要用第三方的包才行。

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

使用自增ID做主键的好处是：

但是，使用自增主键做主键ID也存在一定的问题：

典型回答 ​