数据库里 UUID 和自增 ID 怎么选

选择 UUID 还是自增 ID，不只是数据库偏好。它会影响公开 URL、数据导入、分库分表、索引局部性，以及开发者如何排查记录。

两种选择都合理，关键看这个标识符会流向哪里。

自增 ID 简洁紧凑

连续数字 ID 容易阅读，索引效率高，在内部系统里很舒服：

• 42 很容易输入。
• 数据库索引更紧凑。
• 新行通常写在相近位置。
• 按 ID 排序常常接近创建顺序。

如果是单数据库、内部应用，自增 ID 往往够用。

UUID 更适合分布式生成

当记录可能不只在一个中心数据库里创建时，UUID 更有优势：

• 离线客户端可以先生成 ID 再同步。
• 多个服务可以独立生成 ID。
• 数据导入时更不容易冲突。
• 公开 URL 不暴露行数。
• 事件可以跨系统携带稳定 ID。

需要测试值、API 示例或迁移脚本时，可以用 UUID 生成器 生成样例。

公开 ID 和内部 ID 可以分开

很多系统会同时使用两种 ID：

• 内部数字主键用于数据库 join。
• 公开 UUID 或 slug 用于 URL 和 API 引用。

这样既保留数据库操作的简单性，也避免公开标识符可预测。

索引上的取舍

随机 UUID 会降低索引局部性，因为新值不会自然聚集。对写入非常重的表来说，这可能有影响。

常见选择包括：

• 内部用数字主键，外部暴露 UUID。
• 使用带时间顺序的 ID 格式，兼顾分布式生成和索引局部性。
• 如果表写入压力不大，先测量再优化。

调试上的取舍

连续 ID 更容易在聊天和日志里读出来。UUID 不容易撞，但不容易扫读。

运维和支持工具里，应当让 ID 容易复制、搜索，并清楚标注含义。ID 策略不应该让排查变得过分麻烦。

实用判断

数据内部、集中、性能敏感时，自增 ID 很合适。ID 会跨服务、出现在公开 URL、或需要在入库前生成时，UUID 更合适。

两种需求都存在时，可以有意识地同时使用两者。