告别混乱，拥抱有序：为什么你的下一个ID生成器应该是ULID，而不是UUID

原创于 2025-10-19 04:40:50 发布 · 5.5k 阅读

24 ·

CC 4.0 BY-SA版权

文章标签：

#java

java 专栏收录该内容

42 篇文章

订阅专栏

本文介绍了在使用IntelliJ IDEA过程中遇到的缓存导致的问题及解决方案，通过删除缓存并重启IDE来解决。同时，文章还提到了IDEA在省电模式下关闭代码智能提示功能的现象，建议用户根据需求调整设置。

在软件开发中，我们无时无刻不在与“唯一ID”打交道：数据库里的主键、分布式系统中的追踪ID（Trace ID）、API请求的标识符…… 在这个领域，Java开发者几乎是下意识地就会敲出 UUID.randomUUID()。它就像一个老朋友，可靠、标准、无需任何依赖。

但我们是否想过，这位“老朋友”在现代应用中，尤其是在对数据库性能和日志可观测性要求越来越高的今天，已经显得有些“笨拙”和“粗糙”了？

今天，让我们来深入探讨UUID的“隐痛”，并认识它的继任者——ULID，一个能为你的系统带来秩序与性能的“超级ID”。

UUID (v4): 纯粹的“暴力美学”与隐藏的代价

我们常用的 UUID.randomUUID() 生成的是版本4的UUID。它的核心机制可以用“暴力美学”来形容：在一个由122位随机数构成的、接近无穷大的空间（2^122）里，随机抓一个数出来。

这个空间有多大？你需要每秒生成10亿个UUID，持续85年，才会有50%的概率发生一次碰撞。因此，它的唯一性毋庸置疑。

但这种纯粹的随机性，是有代价的：

1. 致命缺陷：完全无序，日志分析的噩梦

想象一下，你正在排查一个线上问题，需要在日志系统中根据 traceId 追踪一个请求的完整链路。你看到了如下的日志ID：

8a3b0eac-2559-4f36-8b2b-6b2a0c6d7e2f   <-- 10:01:05
e3b0c442-98fc-4299-8e7c-86b2a0c6d7e2f   <-- 10:01:01
1f7f1c1c-8b2b-4b2a-9c6d-7e2f8a3b0eac   <-- 10:01:03

它们是完全乱序的！你无法通过ID本身判断出请求的先后顺序，只能依赖另一个字段——时间戳。这在分析复杂的并发问题时，会让你的效率大打折扣。

2. 隐形杀手：数据库性能的“索引破碎机”

这是UUID最常被诟病的硬伤。当UUID被用作数据库主键（尤其是在MySQL InnoDB这类使用聚簇索引的引擎中）时，一场灾难正在悄然发生：

写入性能急剧下降：由于UUID是无序的，每次 INSERT 操作，数据库都无法简单地将新数据追加到索引的末尾。它必须找到这个随机ID在B+树索引中的“正确位置”，然后插入。这会导致频繁的页分裂（Page Split）和磁盘I/O，使得索引树变得支离破碎，写入性能随着数据量的增长而雪崩。
物理存储混乱：数据行在磁盘上会被随机散落在各处，这对于范围查询和缓存效率都是不利的。

ULID: 兼具优雅与性能的“现代君王”

ULID (Universally Unique Lexicographically Sortable Identifier) 的出现，就是为了解决UUID的上述所有痛点。

它的结构设计得极其巧妙：

[ 48位时间戳 (Timestamp) ] + [ 80位高强度随机数 (Randomness) ]

这个简单的组合，赋予了它超凡的能力：

1. 超能力：按时间字典序排序

ULID的最高位是高精度的时间戳。这意味着，你直接按ULID字符串进行排序，就等同于按它们的生成时间排序！

看看ULID生成的ID：

01H8XJQ2WJ3A1B2C3D4E5F6G7H   <-- 10:01:01
01H8XJQ7K0P8Q9RSTVWXYZ0123   <-- 10:01:03
01H8XJQ9ABCDEFGHIJKLM0P1Q2   <-- 10:01:05

秩序井然！这对于日志分析、事件溯源、游标分页等场景来说，是一个革命性的提升。

2. 高性能：数据库的“最佳拍档”

因为ULID是单调递增的，当它作为主键时：

写入性能极高：新的数据行总是被**追加（Append）**到索引的末尾，这个操作和使用 AUTO_INCREMENT 的整数主键一样快，避免了页分裂和索引碎片。
物理存储有序：数据在磁盘上是按时间顺序紧凑排列的，有利于查询性能和缓存命中率。

3. 开发者友好

ULID使用对URL和人类都更友好的Crockford’s Base32编码，最终表现为一个26位的字符串。它更短、没有特殊字符、不区分大小写，便于复制、沟通和调试。

实战代码：从UUID迁移到ULID

在Java中使用ULID非常简单，只需引入一个轻量级的库。我们推荐 com.github.f4b6a3:ulid-creator。

1. 添加Maven依赖:

<dependency>
    <groupId>com.github.f4b6a3</groupId>
    <artifactId>ulid-creator</artifactId>
    <version>5.2.3</version>
</dependency>

2. 示例一：生成Trace ID

在我们的 AccessLoggingFilter 中，只需一行修改：

import com.github.f4b6a3.ulid.UlidCreator;

// 将这行：
// String traceId = UUID.randomUUID().toString().replace("-", "");
// 替换为：
String traceId = UlidCreator.getMonotonicUlid().toString();

MDC.put("traceId", traceId);

getMonotonicUlid() 确保了即使在同一毫秒内的高并发场景下，生成的ULID依然是严格递增的，极其健壮。

3. 示例二：作为JPA实体的主键

import com.github.f4b6a3.ulid.UlidCreator;
import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.PrePersist;

@Entity
public class User {

    @Id
    @Column(length = 26) // ULID的标准长度是26
    private String id;

    private String username;

    @PrePersist
    public void generateId() {
        if (this.id == null) {
            this.id = UlidCreator.getMonotonicUlid().toString();
        }
    }

    // getters and setters...
}