V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
The Go Programming Language
http://golang.org/
Go Playground
Go Projects
Revel Web Framework
jss
V2EX  ›  Go 编程语言

至今还在用自增 ID 查数据,我想改变,你有好方案吗

  •  
  •   jss · 2019-08-09 13:25:30 +08:00 · 7020 次点击
    这是一个创建于 1918 天前的主题,其中的信息可能已经有所发展或是发生改变。

    各位大佬,给点意见与方案

    39 条回复    2019-08-11 19:42:39 +08:00
    lxrmido
        1
    lxrmido  
       2019-08-09 13:53:47 +08:00 via iPhone
    你想怎样,uuid ?
    SuperMild
        2
    SuperMild  
       2019-08-09 13:57:35 +08:00
    uuid 不好吗?
    yamedie
        3
    yamedie  
       2019-08-09 13:58:48 +08:00
    ObjectId 咯, 上 MongoDB
    Takamine
        4
    Takamine  
       2019-08-09 13:59:07 +08:00 via Android
    uuid_generator_v4()。
    z1154505909
        5
    z1154505909  
       2019-08-09 14:00:17 +08:00
    想改变.弄一些不能用自增 id 解决的需求,
    至于实际使用的时候
    自增能不能满足需求?能,那就用,
    chinvo
        6
    chinvo  
       2019-08-09 14:00:58 +08:00
    如果你在 ID 里面记录时间,可以考虑用 ksuid
    ShangAliyun
        7
    ShangAliyun  
       2019-08-09 14:01:08 +08:00
    各有各的好处,在不怕爬虫的场景,自增增加可读性挺好的,我博客文章现在还是自增 id
    chinvo
        8
    chinvo  
       2019-08-09 14:01:23 +08:00
    或者 Snowflow ID
    keepeye
        9
    keepeye  
       2019-08-09 14:02:45 +08:00
    用关系型数据库,自增 ID 咋了?我敢说大部分项目自增 id 足够了,你看 v2 不也是吗?有啥必须的理由不能用自增 id 呢?
    ayonel
        10
    ayonel  
       2019-08-09 14:10:50 +08:00
    自增 id 的好处非常多。uuid 的随机性,会导致主键索引频繁的分裂、合并,影响插入性能。另外,主键使用 id 的话,数据量小,查询起来也比 uuid 稍快点。
    SpiderShrimp
        11
    SpiderShrimp  
       2019-08-09 14:11:33 +08:00
    uuid
    WuwuGin
        12
    WuwuGin  
       2019-08-09 14:12:10 +08:00
    @keepeye 自增的拓展性较差,分布式用 uuid 是个好办法,虽然说大部分应用远达不到需要分布式的量级,不过养成习惯也是好的。唯一缺点大概就是排序不能用主键了。
    collery
        13
    collery  
       2019-08-09 14:14:06 +08:00
    主键自增 id 无所谓。 就算分库分表也不能更具 id 这种无意义的键来分。
    airyland
        14
    airyland  
       2019-08-09 14:17:00 +08:00
    @keepeye 分布式可能比较麻烦,自增 id 导致数据极其容易被全量遍历抓取,商业数据应该避免。
    lihongjie0209
        15
    lihongjie0209  
       2019-08-09 14:18:55 +08:00
    @airyland #14 这个问题和分布式没什么关系
    airyland
        16
    airyland  
       2019-08-09 14:27:27 +08:00
    @lihongjie0209 我不是直接回复这个问题,是回复上面用户。
    flyingghost
        17
    flyingghost  
       2019-08-09 14:34:32 +08:00   ❤️ 1
    其实问题都没有明确。
    自增 ID 怎么了?遇到了什么问题?
    分布式?
    安全隐秘?
    全局唯一性?
    全局自增有序?
    都有增强 /替代方案。

    如果只是看着不爽,那闭着眼睛用好了。自增 ID 缺点不少,优点也是大把。何必瞧人家土呢?再土能土得过 TCP/IP 和冯诺依曼计算机架构?还不是天天用。
    dk7952638
        18
    dk7952638  
       2019-08-09 14:58:04 +08:00
    uuid 对索引极不友好,小项目自增,大项目分布式用雪花算法
    wensonsmith
        19
    wensonsmith  
       2019-08-09 15:03:41 +08:00
    如果只是安全隐秘, 可以参考 laravel 扩展包 hash_id

    如果是分布式 /全局唯一 /全局自增有序,Snowflake, 美团的 Leaf , 微信的发码机制可以看看
    jifengg
        20
    jifengg  
       2019-08-09 15:21:38 +08:00
    同意 @flyingghost 的观点。要不要用自增要看具体的使用场景。
    1109599636
        21
    1109599636  
       2019-08-09 15:34:38 +08:00
    做个中间件,还是用 id 但是返回经过中间件转换成"杂乱"的字母字符串,解析请求也经过中间件把字母字符串转换成 id
    mineqiqi
        22
    mineqiqi  
       2019-08-09 16:36:48 +08:00
    什么级别的用户量?还是说你想了解分布式自增 id 解决方案,自行百度谷歌
    Oktfolio
        23
    Oktfolio  
       2019-08-09 16:43:45 +08:00
    反正我是能用 自增 ID 的情况下就用 自增 ID,毕竟在 MySQL 上性能更好。分布式用 UUID 不会遇到重复吗? snowflake 了解一下。
    annielong
        24
    annielong  
       2019-08-09 17:09:15 +08:00
    内部用自增,外部用 uuid
    xfriday
        25
    xfriday  
       2019-08-09 19:47:55 +08:00
    为了和别人不一样,强行不用自增主键,这不是沙雕行为么?用什么方案完全取决于需求
    RH
        26
    RH  
       2019-08-09 19:48:45 +08:00 via iPhone
    snowflow
    inwar
        27
    inwar  
       2019-08-09 20:04:22 +08:00 via Android
    同 snowflake,国内有个美团 leaf 做了一些集成和优化可以了解一下,基本到手可用
    reus
        28
    reus  
       2019-08-09 20:43:57 +08:00
    自增 id 有什么问题?爬虫?你难道不做权限验证?
    uxstone
        29
    uxstone  
       2019-08-09 20:53:24 +08:00
    极其不建议用 UUID
    janxin
        30
    janxin  
       2019-08-09 23:32:53 +08:00 via iPad
    完全 get 不到需求
    littlewing
        31
    littlewing  
       2019-08-09 23:42:06 +08:00
    可以用 UUID 啊,随便你用啥,如果用 InnoDB 的话,最好主键是自增 ID,因为自增 ID 对 B+树的插入效率和空间利用率最高,如果是用 LSM-Tree 比如 levelDB 之类的,应该无所谓了,没太了解过
    zjsxwc
        32
    zjsxwc  
       2019-08-09 23:50:00 +08:00 via Android
    自增 id 是有好处的,
    可以提高查询与处理效率(比如二分法),
    可以作为唯一原子数据在高并发时使用(比如抢购活动时,作为抢中依据),
    可以提高可读性(对于 24 位头尾字符都一样,只有中间一两个字符不同的 uuid,我是无法肉眼直接分辨的)
    ikaros
        33
    ikaros  
       2019-08-10 09:08:43 +08:00
    这个问题我想了好久, UUID 太长太占空间,自增一是反爬问题,二是很容易被人猜到业务量,解决方法的话可以用 short uuid(类似 twitter 的 snowflake,这个其实也比较长,是个比较大的整数,而且需要和数据库交互一次),思考了一下,最后我用的是随机自增,每次生成 ID 加上一个范围内的随机数,要做分布式的话可以预估业务量仿照 snowflake 在前面加上机器编号
    janxin
        34
    janxin  
       2019-08-10 09:42:47 +08:00
    @ikaros 这种需求推荐了解一下类似 Youtube 和 bit.ly 的 hashids,有多种语言的实现。

    hashids.org/
    hangszhang
        35
    hangszhang  
       2019-08-10 14:35:57 +08:00
    自增 id 对于索引很友好
    explore365
        36
    explore365  
       2019-08-10 18:26:56 +08:00
    自增 ID,索引友好。
    至于反爬?一点都不是问题,只有脑子的问题。
    sleepm
        37
    sleepm  
       2019-08-10 20:23:10 +08:00 via Android
    id 只是索引,又不展现出来,前台显示的可以是 order_id
    知乎有讨论淘宝订单号规则的
    我也见证过京东订单号从 5 开头,到 7 开头,再到 10 开头。。
    ziiber
        38
    ziiber  
       2019-08-11 01:07:30 +08:00
    自增 ID 什么的没什么吧,楼上说什么爬虫遍历的,谁规定一定要把自增 ID 显示出来了?不会显示其他自定义的嘛?
    stanjia
        39
    stanjia  
       2019-08-11 19:42:39 +08:00
    雪花 is
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   942 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 20:56 · PVG 04:56 · LAX 12:56 · JFK 15:56
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.