数据库主键之争：为什么大厂都开始用 UUID 而不是自增 ID？

自增 ID (Auto Increment) 的落幕

在单机 MySQL 时代，INT AUTO_INCREMENT 是绝对的王者。它简单、紧凑、查询快。
但随着业务扩张，分库分表和微服务架构的到来，自增 ID 的缺点暴露无遗：

1. 数据泄露风险：
   如果你也是个爬虫写手，看到 URL 是 user/1000，你一定会顺手试试 user/1001。竞争对手可以轻松猜出你的日订单量、用户总数。

2. 分库分表地狱：
   当你要把数据从一个库拆到两个库时，ID 冲突会让你痛不欲生。你得精心规划步长（Server A 生成奇数，Server B 生成偶数），运维成本极高。

3. 无法离线生成：
   必须依赖数据库连接才能拿到 ID。如果数据库挂了，整个插入逻辑就瘫痪了。

UUID：分布式的救星？

UUID (Universally Unique Identifier) 是一个 128 位的长数字，通常用 32 个十六进制数表示，中间用连字符隔开。
例如：550e8400-e29b-41d4-a716-446655440000

优点

• ✅ 全球唯一：你不需要中心化的发号器，哪怕在断网的火星上生成一个 UUID，把它带回地球，也不会和现有的重复。
• ✅ 安全性：完全无序，没人能猜出下一个 ID 是什么，也没人能推算出你的业务量。

缺点

• ❌ 太长了：作为数据库主键，它比 INT 占用的空间大得多，索引效率低。
• ❌ 无序性：导致 B+ 树索引频繁分裂，写入性能下降（UUID v1/v2 基于时间有序，但暴露 MAC 地址；v4 完全随机）。

终极方案：Snowflake（雪花算法）

Twitter 发明的 Snowflake 算法结合了两者的优点：

• 它是一个 64 位的 Long 型数字（比 UUID 短）。
• 趋势递增（基于时间戳），索引性能好。
• 不依赖数据库，分布式生成。

既然 Snowflake 这么好，为什么还需要 UUID？

因为 UUID 简单。
Snowflake 需要配置 Worker ID，需要解决时钟回拨问题，实现起来有一定门槛。
对于非高频写入、不需要极致性能的业务（比如生成 API Key、Session ID、上传文件名），UUID 依然是最佳选择。它是“最快能用”的方案。

---

你的项目适合用什么？

• 内部系统 / 小微项目：自增 ID（简单就是美）。
• SaaS / 公开 URL 资源：UUID（保护隐私，防爬虫）。
• 高并发 / 核心交易系统：Snowflake（性能与分布式的平衡）。

需要快速生成一批测试数据？或者给你的新用户生成一个唯一的 API Token？
试试 UUID 在线生成器：

• 支持 UUID v1 (基于时间) 和 UUID v4 (完全随机)。
• 支持批量生成，一键复制。
• 纯前端计算，数据绝不上传，安全无忧。