分布式ID vs 数据库自增ID：如何选择？

这是一个架构设计中绕不开的问题。先给你结论，再详细分析。

🎯 一句话结论

一、数据库自增ID

数据库自增ID是最传统的方式，靠数据库的AUTO_INCREMENT或SEQUENCE生成。

✅ 优势

❌ 劣势

适用场景

• 小型项目，用户量在百万级以下

• 无分库分表计划

• 用户ID不对外暴露

二、分布式ID主流方案对比

三、深度分析

3.1 Snowflake 雪花算法 — 最推荐

雪花算法是分布式ID生成的事实标准，由Twitter开源，64bit长整型（Go中用uint64表示）。

结构图：

0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 1bit(未用) 41bit时间戳(毫秒) 10bit机器ID 12bit序列号

Go语言实现：

package id import ( "errors" "sync" "time" ) type Snowflake struct { mu sync.Mutex startTime int64 // 起始时间戳 (毫秒) machineID int64 // 机器ID (0-1023) sequence int64 // 序列号 (0-4095) lastStamp int64 // 上次生成ID的时间戳 } // 配置参数 (可调整) const ( machineBits = 10 // 机器ID位数 sequenceBits = 12 // 序列号位数 machineMax = -1 ^ (-1 << machineBits) // 最大机器ID: 1023 sequenceMax = -1 ^ (-1 << sequenceBits) // 最大序列号: 4095 timeShift = machineBits + sequenceBits // 22 machineShift = sequenceBits // 12 ) func NewSnowflake(machineID int64) (*Snowflake, error) { if machineID < 0 || machineID > machineMax { return nil, errors.New("machineID out of range") } return &Snowflake{ startTime: 1704067200000, // 2024-01-01 00:00:00 (可自定义) machineID: machineID, }, nil } func (s *Snowflake) NextID() (int64, error) { s.mu.Lock() defer s.mu.Unlock() now := time.Now().UnixMilli() if now < s.lastStamp { return 0, errors.New("clock moved backwards") } if now == s.lastStamp { s.sequence = (s.sequence + 1) & sequenceMax if s.sequence == 0 { // 当前毫秒序列号用完，等待下一毫秒 for now <= s.lastStamp { now = time.Now().UnixMilli() } } } else { s.sequence = 0 } s.lastStamp = now // 组装ID id := ((now - s.startTime) << timeShift) | (s.machineID << machineShift) | s.sequence return id, nil }

使用示例：

// 初始化 (每个服务实例一个唯一machineID，如用IP后10位或Pod Name) worker, _ := NewSnowflake(1) // 生成ID userID, _ := worker.NextID() // 输出如: 1234567890123456789

为什么推荐雪花算法？

• 性能极高：单机每秒可生成几十万ID，无网络开销

• 趋势递增：对MySQL B+Tree索引友好

• 64bit长整型：占用空间小，适合做数据库主键

• 无需外部依赖：不依赖Redis、DB等中间件

• Go语言天然支持：int64类型刚好够用

3.2 如果必须用UUID的情况

以下场景才适合用UUID：

• 分布式文件系统（如对象存储的Key）

• 日志追踪ID（TraceID）

• 临时会话ID

• 数据库非聚簇索引字段

⚠️ 警告：绝对不要用UUID作为MySQL的聚簇索引主键，随机插入会导致页分裂和碎片化！

3.3 数据库自增ID的妥协方案

如果坚持用自增ID但担心暴露信息，可采用双ID策略：

• 数据库主键用自增ID（内部使用）

• 对外暴露用HashID加密或Snowflake生成的公开ID

// 对外暴露的ID使用HashID (保持短小) import "github.com/speps/go-hashids" func EncodeID(id int64) string { hd := hashids.NewData() hd.Salt = "your-salt-key" hd.MinLength = 8 h, _ := hashids.NewWithData(hd) result, _ := h.EncodeInt64([]int64{id}) return result }

四、决策流程图

开始 │ ▼ ┌─────────────────┐ │ 是否分库分表或 │ │ 微服务架构？ │ └─────────────────┘ │ │ 是 否 │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ 使用分布式ID │ │ 用户量会超 │ │ (Snowflake) │ │ 500万吗？ │ └─────────────┘ └─────────────┘ │ │ 是 否 │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ 分布式ID │ │ 数据库自增ID │ │ (预留扩展) │ │ 或Snowflake │ └─────────────┘ └─────────────┘

五、最终推荐

💡经验之谈：如果拿不准，直接上Snowflake。它比自增ID多不了几行代码，但省去了将来迁移的千倍痛苦。微服务架构中，从一开始就使用分布式ID是最稳妥的选择。