UUID 优化方案

虽然 UUID 有很多优点，但也有一些缺点。让我们看看如何优化 UUID，克服它的缺点。

主要问题

1. 无序性问题

影响：

- 数据库索引性能差
- 范围查询慢
- B+ 树频繁页分裂

2. 存储空间大

影响：

- UUID：36 字符
- 占用磁盘空间
- 占用内存
- 索引空间大

3. 可读性差

影响：

- 用户无法理解
- 无法口头传达
- 不便于调试

优化方案

1. UUID v7：时间有序

简介： UUID v7 是 2024 年新提出的标准，专门解决无序性问题。

结构：

Unix 时间戳 (48位)
版本标识 (4位)
随机位 (74位)
变体标识 (2位)

示例：0189dcd0-3e45-7123-8b5e-123456789abc

生成代码：

优势：

✅ 时间有序
✅ 仍然唯一
✅ 标准化
✅ 向后兼容

性能对比：

2. ULID：通用唯一词典排序标识符

简介： ULID（Universally Unique Lexicographically Sortable Identifier）是一个专门设计的可排序唯一标识符。

结构：

时间戳 (48位)
随机数 (80位)

示例：01ARZ3NDEKTSV4RRFFQ69G5FAV

特点：

✅ 时间有序
✅ 128 位空间
✅ URL 安全
✅ 26 字符（比 UUID 短）
✅ 可词典排序

生成代码（JavaScript）：

性能对比：

3. 短 UUID：减少存储

原理： 去掉 UUID 的连字符，使用 Base64 编码。

实现：

对比：

原 UUID：f47ac10b-58cc-4372-a567-0e02b2c3d479（36字符）
短 UUID：9W3tYH1kXJ4rXZw8LQ==（22字符）

节省：38% 存储空间

4. 混合方案：UUID + 时间戳

原理： 结合 UUID 和时间戳，保持唯一性的同时增加有序性。

实现：

优势：

✅ 保持 UUID 的唯一性
✅ 增加时间排序能力
✅ 实现简单
✅ 向后兼容

5. 数据库优化：分区表

原理： 使用 UUID，但通过分区表优化性能。

实现：

数据设计要点

• 核心是在 orders 里保存业务事实，而不是把规则散落在应用逻辑里。
• 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
• 关键字段包括 id、created_at，它们决定后续查询和管理能力。

优势：

✅ 保持 UUID 的便利性
✅ 分区提升查询性能
✅ 按时间范围查询快
✅ 数据管理方便

6. 索引优化：复合索引

原理： 创建包含时间戳的复合索引。

实现：

数据设计要点

• 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
• 查询目标是快速定位状态、任务或资源，避免在关键路径上做大范围扫描。

优势：

✅ 利用时间戳排序
✅ 利用 UUID 唯一性
✅ 查询性能提升
✅ 范围查询优化

优化建议

1. 选择合适的版本

需要时间有序 → UUID v7 / ULID
需要 URL 安全 → ULID
需要兼容性 → UUID v4
需要短 ID → 短 UUID

2. 考虑存储优化

存储空间紧张 → 短 UUID / ULID
查询性能重要 → UUID v7
兼容性重要 → UUID v4

3. 数据库优化

使用 UUID + 复合索引
使用分区表
定期优化索引

最佳实践

1. 新项目推荐

需要有序 → UUID v7
需要短小 → ULID
一般场景 → UUID v7（如果支持）

2. 现有项目迁移

评估迁移成本
测试性能影响
逐步迁移
保持兼容性

3. 混合使用

主键：雪花算法
外键：UUID
追踪：UUID
缓存：UUID

总结

优化方案对比

推荐选择

新项目：

首选：UUID v7
备选：ULID

现有项目：

评估后迁移到 UUID v7
或使用混合方案

下一步

学习了 UUID 及其优化方案后，我们继续学习数据库自增方案。

👉 下一章：数据库自增方案