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

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

  •  
  •   jss · 74 天前 · 4178 次点击
    这是一个创建于 74 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

    hashids.org/
        35
    hangszhang   73 天前
    自增 id 对于索引很友好
        36
    explore365   73 天前
    自增 ID,索引友好。
    至于反爬?一点都不是问题,只有脑子的问题。
        37
    sleepm   73 天前 via Android
    id 只是索引,又不展现出来,前台显示的可以是 order_id
    知乎有讨论淘宝订单号规则的
    我也见证过京东订单号从 5 开头,到 7 开头,再到 10 开头。。
        38
    ziiber   73 天前
    自增 ID 什么的没什么吧,楼上说什么爬虫遍历的,谁规定一定要把自增 ID 显示出来了?不会显示其他自定义的嘛?
        39
    stanjia   72 天前
    雪花 is
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3087 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 31ms · UTC 00:56 · PVG 08:56 · LAX 17:56 · JFK 20:56
    ♥ Do have faith in what you're doing.