MySQL主键策略解析：自增ID与UUID的优劣及选择建议

一、核心特性对比

‌维度‌	‌自增ID‌	‌UUID‌
‌存储空间‌	4-8字节（整型），空间占用极低 ‌	16字节（字符串），空间消耗高 ‌
‌索引性能‌	有序插入减少页分裂，B+树高度低，写入性能优 ‌	随机插入导致30%+页分裂，索引碎片多 ‌
‌唯一性‌	单库唯一，分布式需人工协调 ‌	全局唯一，天然支持分布式 ‌
‌安全性‌	暴露数据量和插入顺序，爬虫风险高 ‌	无序性避免业务信息泄露 ‌
‌查询效率‌	范围查询快5-8倍（如ID>1000）‌	全索引扫描场景增加40% ‌

二、适用场景决策树

mermaid

graph TD A[业务场景] -->|单机/低并发| B[选自增ID] A -->|分布式/分库分表| C[选UUID] B --> D{数据量＞千万？} D -->|是| E[分库分表+自增ID] D -->|否| F[纯自增ID] C --> G{安全性要求高？} G -->|是| H[UUID] G -->|否| I[雪花算法]

1. ‌优先选自增ID‌

• ‌单机高写入场景‌：如订单系统，需极致插入性能 ‌
• ‌存储敏感型系统‌：海量数据下节省23%+存储空间 ‌
• ‌强查询需求‌：范围查询场景性能碾压UUID ‌

2. ‌优先选UUID‌

• ‌分布式架构‌：微服务间数据合并无需协调 ‌
• ‌跨库数据集成‌：如多分支系统数据迁移 ‌
• ‌高安全业务‌：支付流水等防信息泄露场景 ‌

三、性能瓶颈与破解方案

1. ‌自增ID痛点‌

• ‌分布式缺陷‌：分库分表时需设置不同步长防ID冲突 ‌
• ‌高并发锁争用‌：AUTO_INCREMENT锁成吞吐瓶颈 ‌
• ‌解决方案‌：
  • 分段自增（实例编号+自增ID）‌
  • 业务隔离：核心表用自增ID，关联表用UUID ‌

2. ‌UUID缺陷‌

• ‌索引碎片‌：随机写入导致B+树频繁分裂 ‌
• ‌查询劣化‌：全表扫描率提升40% ‌
• ‌优化方案‌：
  • ‌雪花算法‌：时间戳+机器ID+序列号生成局部有序ID ‌
  • ‌压缩存储‌：将UUID转为16进制存储（8字节）‌

四、选型决策矩

‌评估维度‌	自增ID得分	UUID得分	决胜因素
写入性能	★★★★★	★★☆☆☆	顺序写入VS随机写入 ‌
分布式支持	★☆☆☆☆	★★★★★	全局唯一性需求 ‌
存储成本	★★★★★	★★☆☆☆	数据量＞1亿 ‌
安全防护	★★☆☆☆	★★★★★	业务敏感度 ‌

‌终极建议‌：

• ‌单机系统‌：无脑选自增ID，千万级数据量可通过分库分表扩展 ‌
• ‌分布式系统‌：
  • 若吞吐要求高 → 雪花算法 ‌
  • 若安全性优先 → UUID ‌
• ‌混合架构‌：核心业务表用自增ID，跨服务关联表用UUID ‌