温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

_uuid_做主键好吗

发布时间:2026-09-03 02:21:30 来源:亿速云 阅读:96 作者:小樊 栏目:数据库

UUID 做主键可以用,但不一定好,要看具体场景。下面从优缺点、适用场景和常见建议几个角度说清楚。


一、UUID 做主键的优点

1. 全局唯一,适合分布式

  • 不同机器、不同服务生成的 ID 不会冲突
  • 非常适合:
    • 分布式系统
    • 多库多表
    • 数据合并 / 异构系统同步

2. 可在应用层生成

  • 不依赖数据库自增
  • 插入前就知道主键,方便关联写入

3. 不易被猜测

  • 相比 1,2,3… 的自增 ID,UUID 更安全
  • 避免暴露业务规模(如 /user/1001

二、UUID 做主键的缺点(重点)

1. 存储空间大

  • UUID(36 字符或 16 字节)比 INT(4 字节)或 BIGINT(8 字节)大很多
  • 主键会被所有二级索引引用,整体膨胀明显

2. 索引性能差(尤其是 MySQL InnoDB)

  • InnoDB 主键即聚簇索引
  • UUID 无序,导致:
    • 插入时页分裂频繁
    • 索引碎片多
    • 写入性能下降

3. 查询性能不如自增 ID

  • 范围查询、排序、JOIN 效率更低
  • 大量数据下差异明显

三、什么时候“适合”用 UUID 做主键?

✅ 适合:

  • 分布式 / 微服务架构
  • 多数据中心
  • 数据需要离线生成后合并
  • 安全性要求高(不暴露顺序)

❌ 不适合:

  • 单库单表、高并发写入
  • 超大数据量表(千万级以上)
  • 对写入性能和存储成本敏感的系统

四、更好的实践建议

✅ 方案 1:UUID + 自增(推荐)

id BIGINT AUTO_INCREMENT PRIMARY KEY,
uuid CHAR(36) UNIQUE NOT NULL
  • 内部用自增做主键
  • 对外暴露 UUID

✅ 方案 2:有序 UUID(UUIDv7)

  • 时间有序,减少索引碎片
  • 比 UUIDv4 更适合做主键

✅ 方案 3:雪花算法(Snowflake)

  • 分布式 + 趋势递增
  • 性能优于 UUID

五、总结一句话

UUID 做主键:分布式友好,但性能和存储不友好。

如果你愿意,可以告诉我:

  • 用的什么数据库(MySQL / PostgreSQL / …)
  • 是否分布式
  • 数据量级别

我可以直接给你更合适的表结构设计

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI