V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
polyang
V2EX  ›  程序员

MySQL 主键用自增好还是 UUID、雪花算法 ID 好?用自增+UUID 会不会好一点?

  •  
  •   polyang · 53 天前 · 3201 次点击
    这是一个创建于 53 天前的主题,其中的信息可能已经有所发展或是发生改变。
    我想的是一个表有两个基本字段 id 和 primary_key,id 是自增,且为主键; primary_key 为 UUID,是逻辑主键,表与表之间通过 primary_key 来关联,对前端也只暴露 primary_key 。
    31 条回复    2021-08-01 06:14:22 +08:00
    long2ice
        1
    long2ice   53 天前
    自增效率最高,UUID 不会暴露数据量,但是效率低,看业务场景吧
    ThanksSirAlex
        2
    ThanksSirAlex   53 天前
    用 UUID 你要自己有一个能竟然范围查找和排序的字段,雪花算法是分布式自增 id,如果你是单机,就不需要考虑这个东西
    CodeCodeStudy
        3
    CodeCodeStudy   53 天前
    数据量不大就不要用雪花算法了,那是给分布式搞的,数字太大,看着头疼
    emeab
        4
    emeab   53 天前
    表和表直接直接用主键不也可以吗. 你对外不暴露就行了.
    xwayway
        5
    xwayway   53 天前
    我们现在一般是自增主键做 id,业务上设置个唯一键
    RRRoger
        6
    RRRoger   53 天前
    postgres integer 最大是 2^31-1

    不知道 MySQL 有没有这样的问题
    codespots
        7
    codespots   53 天前
    @RRRoger 换 bigint 啊 2^63-1 unsigned 2^64-1
    AquanllR
        8
    AquanllR   53 天前
    雪花算法 ID,可以兼容后期分布式架构,但是限制了 1024 个`workerID`,可以按自己业务架构定向去使用哪种方案,小项目单体自增完全 ok 。
    AquanllR
        9
    AquanllR   53 天前
    @AquanllR 自增和雪花,都是增量的,更加适合 mysql 的索引,UUID 不太适合索引~
    Lemeng
        10
    Lemeng   53 天前
    做的自增
    joesonw
        11
    joesonw   53 天前
    不想暴露数据量, 数据在后端 hashid 一下就好. 雪花不允许服务器时间有回滚的, 实施起来难度也不小.
    wei745359223
        12
    wei745359223   53 天前
    可以用 hashid 相互转换自增 ID
    potatowish
        13
    potatowish   53 天前 via iPhone
    数据表当然是存原始数据,敏感数据 hash 一下再对外暴露
    caixiaomao
        14
    caixiaomao   53 天前
    用自增 id 比较多
    aragakiyuii
        15
    aragakiyuii   53 天前 via iPhone   ❤️ 1
    mysql 主键 clustered index 用 uuid 简直是灾难
    Numbcoder
        16
    Numbcoder   53 天前
    UUID 这种垃圾还有人用吗,既不能防碰撞,又是无序,还占空间。
    生成唯一 ID 的方式那么多,再不济自己根据业务需求加随机数生成的 ID 也比 UUID 好啊
    aragakiyuii
        17
    aragakiyuii   53 天前 via iPhone
    @Numbcoder uuid 优势就是简单😂不过还是得分数据库,postgres 支持 uuid 类型,用 16 字节存储 binary 数据。不是聚簇索引效率不会很差,肯定比不过自增 id 就是了
    xuanbg
        18
    xuanbg   53 天前
    自增最大的问题是想要知道 id 还要读一次。。。uuid 和雪花就没这毛病。不过 uuid 虽然简单,但是不利于索引。

    so,还是雪花好了,写个雪花 id 生成器没几行代码。
    Rocketer
        19
    Rocketer   53 天前
    千万别用 uuid,这玩意效率不高,暗坑不少。

    比如版本问题,你如果用多种数据库(比如 SQL Server 和 MongoDB ),你会发现他们默认的 uuid 版本不一样,不专门设置一下就无法愉快地一起玩耍。

    我现在都用雪花算法,直接用来做主键就好了,无须再多一个 primary_key 。
    jorneyr
        20
    jorneyr   52 天前
    我喜欢用雪花,因为在业务层未插入到数据库的时候就可以生成好 ID,尤其是同一个业务中要处理多个用 ID 关联的对象,业务层可以把他们依赖的 ID 生成好直接使用,处理好关系后用事务保存到数据库。如果用自增 ID,得按照先后顺序保存到数据库并且查询得到最新的 ID,然后再处理关系,比雪花麻烦一些,业务逻辑写起来也麻烦。
    xxfye
        21
    xxfye   52 天前 via Android
    uuid_short 无符号自增长整形
    唯一缺点就是作为默认值的话,需要 mysql8
    offswitch
        22
    offswitch   52 天前
    uuid 不要用,聚集索引有序,会引起频繁页分裂和页合并。
    liuzhaowei55
        23
    liuzhaowei55   52 天前 via iPhone
    主键用自增 id,业务用 random string 够用了,不放心的话入库前先查一下
    Verizon
        24
    Verizon   52 天前
    UUID 插入性能太差了 高性能 MYSQL 中有案例当表数据增长 到 300 万行时 UUID 比自增慢了 4 倍 而且索引占用空间是自增的 1.7 倍 具体原因跟 22 楼说的一样
    chenqh
        25
    chenqh   52 天前
    用 redis 写一个简单的带时间的自增 id 就好了
    hushao
        26
    hushao   52 天前 via iPhone
    没特殊业务需求,一律自增。别的都是折腾
    charlie21
        27
    charlie21   52 天前
    如果是只用自增,如何用最简单的方式避免暴露数据
    mreasonyang
        28
    mreasonyang   52 天前 via iPhone
    非 C 端用自增就行了,C 端建议新项目伊始就用 Snowflake,不然后面体量大了想改就不容易了。UUID 方案如楼上所说没有任何优势所以就不要考虑了。

    至于如何实现可靠的分布式 Snowflake 有很多轮子,推荐这款: https://github.com/Meituan-Dianping/Leaf
    vanityfairn
        29
    vanityfairn   52 天前
    为什么要用 uuid 折磨自己。。如果小业务,那也随意把?但是自增 id 不香么
    honkki
        30
    honkki   52 天前
    @Rocketer 想请教一下雪花算法生成的 id 做主键 性能是不是比递增主键性能差呢 存在数据页分裂情况吗
    xuanbg
        31
    xuanbg   51 天前
    @honkki 单调递增的效果和自增是一模一样的,整体而言,因为少了一次读操作,代码的效率更高。
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   807 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 19ms · UTC 20:56 · PVG 04:56 · LAX 13:56 · JFK 16:56
    ♥ Do have faith in what you're doing.