UUID 使用场景

UUID 在实际生产中有许多适合的使用场景。让我们看看哪些场景最适合使用 UUID。

理想场景

1. 消息追踪 ID

场景描述：在微服务架构中追踪一个请求的完整调用链。

为什么适合：

✅ 全局唯一：每个请求有唯一 ID
✅ 无需协调：各服务独立生成
✅ 生成速度快：不影响请求性能
✅ 可携带：在 HTTP Header 中传递

实现示例：

2. 会话 ID

场景描述：Web 应用中标识用户会话。

为什么适合：

✅ 随机性强：难以被猜测
✅ 安全性高：不易被攻击
✅ 无需持久化：临时使用
✅ 无需有序：会话无需排序

实现示例：

3. 日志追踪 ID

场景描述：在海量日志中快速定位特定请求的所有日志。

为什么适合：

✅ 全局唯一：精确匹配
✅ 生成快：不影响日志性能
✅ 可搜索：便于索引和查询
✅ 可关联：关联到业务 ID

实现示例：

4. 分布式事务 ID

场景描述：在分布式事务中标识一个全局事务。

为什么适合：

✅ 全局唯一：避免事务冲突
✅ 无需协调：各服务独立生成
✅ 可传递：在服务间传递
✅ 可追溯：追踪事务流程

实现示例：

5. 临时文件名

场景描述：生成临时文件名，避免冲突。

为什么适合：

✅ 唯一性：文件名不冲突
✅ 随机性：不易被猜测
✅ 临时性：短期使用即可
✅ 无需有序：临时文件无需排序

实现示例：

6. API 请求 ID

场景描述：API 中标识每个请求。

为什么适合：

✅ 唯一标识：精确匹配请求
✅ 问题追踪：快速定位问题
✅ 防重放：防止请求重放
✅ 无需有序：请求无需排序

实现示例：

7. 测试数据 ID

场景描述：在测试环境中生成测试数据。

为什么适合：

✅ 快速生成：无需手动创建
✅ 唯一性：避免冲突
✅ 无需有序：测试数据无需排序
✅ 临时性：测试完成后清理

实现示例：

边缘场景

8. 数据库外键

场景描述：作为外键关联其他表。

为什么可以使用：

✅ 全局唯一：不会冲突
✅ 分布式：多表独立
⚠️ 无序：可能影响性能
⚠️ 存储大：占用空间

使用建议：

✅ 适合：关联表、日志表
❌ 不适合：主表、核心表

9. 缓存键

场景描述：在缓存系统中作为键。

为什么适合：

✅ 唯一性：键不冲突
✅ 分布式：多节点缓存
✅ 随机性：缓存分布均匀

实现示例：

不适合场景

❌ 订单号

原因：

- 需要可读性
- 需要有序性
- 需要短小

推荐：号段模式

❌ 用户 ID

原因：

- 需要有序性
- 需要短小
- 需要便于查询

推荐：雪花算法

❌ 支付流水号

原因：

- 需要可追溯
- 需要有序
- 需要安全性

推荐：号段模式 + 加密

选择指南

使用 UUID 的检查清单

• 需要全局唯一？
• 有序性不重要？
• 生成速度要求高？
• 无需中央协调？
• 无需持久化排序？
• 存储空间充足？

如果以上都满足，那么 UUID 是不错的选择。

最佳实践

1. 使用合适的版本

2. 考虑存储格式

3. 建立索引

数据设计要点

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

4. 避免作为主键

数据设计要点

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

总结

何时选择 UUID

选择 UUID：

✅ 消息追踪
✅ 会话管理
✅ 日志追踪
✅ 临时数据
✅ 测试数据

不选择 UUID：

❌ 订单号
❌ 用户 ID
❌ 支付流水
❌ 商品 ID
❌ 核心业务 ID

下一步

了解了 UUID 的使用场景后，我们学习 UUID 的优化方案。

👉 下一节：优化方案