在MySQL中生成唯一分布式ID的多种方案与对比（UUID, Snowflake）

新闻中心 NEWS CENTER

您当前位置：首页 > 新闻中心 > 网络学院

在MySQL中生成唯一分布式ID的多种方案与对比（UUID, Snowflake）

2025-09-10

浏览次数：次

返回列表

答案：UUID和Snowflake是生成分布式ID的两种常见方案，UUID简单但无序且占用空间大，Snowflake趋势递增利于索引但实现复杂需处理时钟回拨；数据库自增+步长和Redis自增也适用不同场景，选择需权衡性能、有序性、可用性和复杂度。

在mysql中生成唯一分布式id的多种方案与对比（uuid, snowflake）

生成唯一分布式ID，在MySQL中，主要目标是保证在大规模分布式系统中ID的全局唯一性和高并发下的生成效率。UUID和Snowflake是两种常见的选择，但各有优劣。

UUID虽然简单易用，但其无序性可能导致数据库索引效率降低，占用存储空间也较大。Snowflake算法则能生成趋势递增的ID，有利于数据库索引优化，但实现相对复杂，需要考虑时钟回拨等问题。

解决方案

UUID (Universally Unique Identifier)
- 原理： 基于时间戳、MAC地址、随机数等生成，保证在理论上的全局唯一性。
- 优点： 简单易用，MySQL内置函数
```
UUID()
```
  即可生成。
- 缺点：
  - 无序性： 插入数据库时可能导致页分裂，影响写入性能，特别是对于InnoDB引擎。
  - 空间占用： 128位，占用空间较大。
  - 可读性差： 不易于人工识别和调试。
- 适用场景： 对ID的有序性要求不高，且数据量较小的场景。例如，作为某些非关键业务的ID。
- 示例：
```
SELECT UUID();
-- 输出：'a1b2c3d4-e5f6-7890-1234-567890abcdef'
```

Snowflake算法

原理： 生成一个64位的Long型ID，通常由以下几部分组成：
- 符号位 (1 bit)： 通常为0，表示正数。
- 时间戳 (41 bits)： 记录毫秒级的时间戳，可以支持约69年的时间。
- 工作机器ID (10 bits)： 用于区分不同的机器节点，最多支持1024个节点。
- 序列号 (12 bits)： 用于在同一毫秒内生成不同的ID，每毫秒最多生成4096个ID。
优点：
- 趋势递增： 有利于数据库索引优化，减少页分裂。
- 高并发： 可以在同一毫秒内生成多个ID。
- 可扩展性： 可以通过增加机器节点来提高ID生成能力。
缺点：
- 实现复杂： 需要自己编写代码实现，或者使用现成的开源库。
- 时钟回拨问题： 如果服务器时钟发生回拨，可能导致生成重复的ID。需要进行处理。
适用场景： 对ID的有序性和性能要求较高，且数据量较大的场景。例如，订单ID、用户ID等。

示例 (J*a实现)：

public class SnowflakeIdWorker {

    private long workerId;
    private long datacenterId;
    private long sequence = 0L;

    private long twepoch = 1288834974657L;

    private long workerIdBits = 5L;
    private long datacenterIdBits = 5L;
    private long maxWorkerId = -1L ^ (-1L << workerIdBits);
    private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
    private long sequenceBits = 12L;

    private long workerIdShift = sequenceBits;
    private long datacenterIdShift = sequenceBits + workerIdBits;
    private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
    private long sequenceMask = -1L ^ (-1L << sequenceBits);

    private long lastTimestamp = -1L;

    public SnowflakeIdWorker(long workerId, long datacenterId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        if (datacenterId > maxDatacenterId || datacenterId < 0) {
            throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
        }
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }

    public synchronized long nextId() {
        long timestamp = timeGen();

        if (timestamp < lastTimestamp) {
            throw new RuntimeException(
                    String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }

        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0L;
        }

        lastTimestamp = timestamp;

        return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift) | (workerId << workerIdShift) | sequence;
    }

    protected long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    protected long timeGen() {
        return System.currentTimeMillis();
    }
}

数据库自增ID + 步长
- 原理： 利用MySQL的自增ID特性，并设置合适的步长，分配给不同的机器节点。
- 优点： 简单易用，不需要额外的代码实现。
- 缺点：
  - 依赖数据库： 依赖数据库的可用性，如果数据库出现故障，则无法生成ID。
  - 扩展性有限： 扩展机器节点需要修改数据库配置。
  - ID连续性： ID不是完全连续的，因为每个节点分配的ID之间存在步长。
- 适用场景： 对ID的连续性要求不高，且机器节点数量较少的场景。
- 示例：
  - 节点1：
```
AUTO_INCREMENT = 1, INCREMENT = 2
```
  - 节点2：
```
AUTO_INCREMENT = 2, INCREMENT = 2
```
  这样，节点1生成的ID为1, 3, 5, 7...，节点2生成的ID为2, 4, 6, 8...。
  Project IDX
  Google推出的一个实验性的AI辅助开发平台
  166 查看详情
Redis自增ID
- 原理： 使用Redis的
```
INCR
```
  命令，实现原子性的自增操作。
- 优点：
  - 高性能： Redis的读写性能非常高，可以满足高并发的需求。
  - 简单易用： Redis的API非常简单，容易上手。
- 缺点：
  - 依赖Redis： 依赖Redis的可用性，如果Redis出现故障，则无法生成ID。
  - ID连续性： ID是连续的，但如果Redis重启，可能会丢失一部分ID。
- 适用场景： 对ID的连续性要求不高，且需要高性能的场景。
- 示例：
```
Jedis jedis = new Jedis("localhost", 6379);
Long id = jedis.incr("order_id");
jedis.close();
System.out.println("Generated ID: " + id);
```