当前位置：首页 > news >正文

如何选择合适的主键id?

news 来源：原创 2025/5/15 7:57:39

目录标题

MySQL主键一定是自增的吗？
自增id、uuid、雪花算法谁更合适？
详细聊聊 UUID
详细聊聊雪花算法

在数据库设计中，选择合适的主键对于数据表的性能和数据完整性都非常重要。接下来，让我们探讨一下自增id、uuid和雪花算法，以便更好地理解哪种适合作为主键。

MySQL主键一定是自增的吗？

常见的一个误解是认为MySQL的主键一定是自增的，但实际上，主键并非必须是自增的。主键可以根据需求自行选择，可以选取任何数据类型作为主键！通常单独创建一个自增字段作为主键的好处包括自增id是数字，比UUID占用的位数少，节省存储空间。由于id是递增的，在B+Tree索引中查询效率高。在分页时，通过id解决深度分页问题。然而，使用自增主键也存在问题在分库分表时，无法依赖单表的自增主键作为主键，可能导致重复和冲突。由于id是自增的，系统可能存在一定安全风险，规律性可能为潜在攻击者提供线索。

深度分页问题是指在进行分页查询时，随着页码（偏移量）的增加，数据库需要跳过大量记录，导致查询性能急剧下降。主要原因是偏移量过大导致的索引失效和资源消耗增加。使用自增ID，可以采用键值分页（Keyset Pagination）的方法，避免使用OFFSET，从而提高查询性能。具体做法是：

在第一次查询时，获取当前页的最后一条记录的ID。
在下一次查询时，使用这个ID作为起点，继续查询下一页的数据。

自增id、uuid、雪花算法谁更合适？

我觉得吧没有好不好，只有需求场景适合不适合。三者都有各自的优缺点，和适合的场景。

自增id，在MySQL中可以通过设置 AUTO_INCREMENT 属性实现id的自增长。

优点
- 自增id是数字，占用的位数比uuid小多了，所以在存储空间上也节省很多；
- id是递增的，因此在B+Tree索引时，查询效率较高。在分页的时候，也可以通过id解决深度分页问题。
缺点
- 当我们做分库分表的时候，就没办法依赖一张表的自增主键来作为主键id了，这样就会发生重复导致冲突的问题；
- 因为id是自增的，那么就可以预测到，给系统带来了一定的安全风险。

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

优点
- 无论使用不同的算法生成，几乎都可以保证在全球范围内唯一，避免了多台机器之间主键冲突的问题，适用于分布式系统后中；
- 采用随机数生成的UUID很难被猜测出来，对于需要保密性的应用场景较为合适。
缺点
- UUID通常以128位的字符串形式存储，占用的存储空间比较大；
- 因为UUID不是自增的，所以在做范围查询的时候是不支持的；
- 再就是查询效率低下：
  - 比如说：在UUID列上创建索引，因为它很长，索引的也会变得非常大。大的索引会占用更多的磁盘空间，导致缓存命中率下降，进而增加了磁盘I/O的需求。另外，大的索引还会导致查询时内存开销增加；
  - 另外，因为UUID不自增的，新插入的值可能会插入到叶子节点的中间位置。这可能导致B+树平衡操作频繁进行，从而增加了写入的开销。树的平衡操作涉及到数据的重新排序和移动，这还会影响到查询的性能。

雪花算法，是Twitter研发的一种分布式ID生成算法，它可以生成全局唯一且递增的id。算法的核心思想是将一个64位的id划分为多个部分，分别对应着符号位、时间戳、数据中心标识、机器标识、序列化。

优点
- 全局唯一：雪花算法生成的ID是64位的整数，可以保证在全球范围内唯一，适用于分布式系统；
- 有序性：生成的ID是递增的，这对于数据库中的索引和查询优化非常有利；
- 高性能：生成ID的速度非常快，每秒可以生成数十万个ID，适合高并发场景；
- 低存储成本：64位的整数相比128位的UUID占用更少的存储空间；
- 可追溯性：ID中包含了时间戳信息，可以通过ID反推出生成时间，便于日志记录和问题排查。
缺点
- 时间回拨问题：如果服务器的时间被回拨，可能会导致生成的ID重复。可以通过配置NTP同步时间来缓解这个问题；
- 依赖系统时间：生成ID依赖于系统时间，如果系统时间不准确，可能会影响ID的生成；
- 单点故障：默认情况下，雪花算法的ID生成器是单点的，如果ID生成器出现故障，可能会影响整个系统的可用性。可以通过集群部署来解决这个问题；
- ID泄露：由于生成的ID是有序的，可能会暴露一些系统内部的信息，例如生成ID的时间和机器编号。对于需要高度保密的应用场景，这可能是一个安全风险。

总的来说

自增ID：适用于单个数据库实例或单表的情况，适用于低并发、简单应用；
UUID：适用于需要全局唯一且对安全性要求较高的分布式系统，如金融交易系统中的订单号；
雪花算法：适用于需要全局唯一且对性能和存储有较高要求的分布式系统，尤其是高并发场景。如：大型电商平台中的订单号、社交网络中的用户ID。

详细聊聊 UUID

UUID 中文意思就是“全局唯一标识符”，它的目标是在同一时空中的所有机器都是唯一的。UUID 是一种128位的数字，通常为32个十六进制数字，分为五组表示。

优点：UUID的性能比较高，不依赖网络，本地就可以生成，使用起来也比较简单；
缺点：长度过长、没有任何含义；
不自增有好处有坏处，
- 好处是没有可溯性，适用于安全性要求较高的应用；
- 坏处是新插入的值可能会插入到叶子节点的中间位置。这可能导致B+树平衡操作频繁进行，从而增加了写入的开销。树的平衡操作涉及到数据的重新排序和移动，这还会影响到查询的性能。

标准的UUID：43c20451-f3d5-4829-99aa-4ceca2a32d6d（8-4-4-4-12）。

UUID 在具体实现上有多个版本，java中的java.util.UUID生成的UUID是V3和V4。以下是各个版本的实现：

v1. 基于时间戳的UUID
基于时间戳、随机数、MAC地址，适用于需要时间顺序的场景。
由于在算法中使用了MAC地址，这个版本的UUID可以保证在全球范围的唯一性。但与此同时，使用MAC地址会带来安全性问题。（mac地址就是网卡上的唯一标识，通过获取到一个MAC地址生成的大量UUID，可以被反向解析出MAC地址，进而获取设备的物理位置或用户身份信息，遭受网络攻击。）

v2. DCE 安全版本
基于时间戳、MAC地址和POSIX UID/GID，较少使用。
相较于v1基于时间戳UUID算法相同，但是会把时间戳的前4位换为POSIX的UID或GID。这个版本的UUID在实际上较少用到。

v3. 基于命名空间的UUID
基于命名空间和名称的MD5哈希，适用于需要根据特定名称生成唯一标识的场景。格式：md5(namespace + name)
名称和命名空间的组合确保了生成的UUID的唯一性。

v4. 基于随机数的UUID
完全基于随机数，最常用的版本，适用于需要高度保密性的场景。
生成的UUID是完全随机的，适用于需要高度保密性的场景。但是因为是基于随机数的，所以并不适合数据量特别大的场景。

v5. 基于名称空间的UUID
基于命名空间和名称的SHA-1哈希，适用于需要更高安全性的场景。格式：sha1(namespace + name)
与v3类似，只是散列值计算使用SHA-1哈希算法，生成的UUID更加安全。

详细聊聊雪花算法

雪花算法（Snowflake Algorithm）是由Twitter开发的一种分布式ID生成算法，旨在生成全局唯一且递增的ID。该算法通过将64位的ID划分为多个部分来实现这一目标，每个部分都有特定的含义和作用。
雪花算法的结构大致如下：

符号位（1位）：固定为0，表示这是一个正数。
时间戳（41位）：表示毫秒级的时间戳，从某个起始时间（例如2022-01-01 00:00:00）开始计算。41位的时间戳可以表示大约69年的时间范围。
数据中心标识（10位）：用于标识不同的数据中心，最多可以有1024个数据中心。
机器标识（10位）：用于标识同一数据中心内的不同机器，最多可以有1024台机器。
序列号（12位）：用于在同一毫秒内生成多个ID时，确保ID的唯一性。最多可以有4096个序列号。

基于以上结构，雪花算法在唯一性保证方面就有很多优势：
● 首先，时间戳基于最高位，保证新生成的id比旧的id大；
● 其次，引入了数据中心标识和机器标识，该标识都可以手动配置，帮助业务来保证不同的数据中心和机器能生存不同的id；
● 还有就是引入了序列号，用来解决同一毫秒内多次生成ID的问题（每次生成id时序列号都会自增，因此不同id在序列号上有区别）；

所以，基于时间戳+数据中心标识+机器标识+序列号，保证了不同进程中主键的不重复，在相同进程中主键的有序性。
但是在实际使用中会存在时钟回拨问题，即雪花算法使用时间戳作为生成id的一部分，如果系统时钟回拨（即时间倒退），可能会导致生成的id不递增。为了处理这种情况，雪花算法通常会抛出异常或等待时钟恢复到正常状态；

美团leaf引入了zookeeper来解决时钟回拨问题，其大致思路为“每个Leaf运行时定时向 zk 上报时间戳，每次 leaf 服务启动后，先校验本地时间与上次发 id 的时间，再校验与 zk 上所有节点的平均时间戳。如果任何一个阶段有异常，那么就会启动失败报警”
百度的UidGenerator中有两种UidGenerator，
- 其中DefautlUidGenerator使用了System.currentTimeMillis()获取时间与上一次时间比较，当发生时钟回拨时，抛出异常。
- 而CachedUidGenerator使用是放弃了对机器的时间戳的强依赖，而是改用AtomicLong的incrementAndGet()来获取下一次时间，从而脱离了对服务器时间的依赖。

目录标题

MySQL主键一定是自增的吗？

自增id、uuid、雪花算法 谁更合适？

详细聊聊 UUID

详细聊聊 雪花算法

相关文章：

自增id、uuid、雪花算法谁更合适？

详细聊聊雪花算法