用 uuid 和自增作为主键，各有什么有缺点呢？

[hanshijun]

萌新请教，大佬轻喷⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄

[wps353]

@lihongjie0209
这个 autoinc_lock 可以通过 innodb_autoinc_lock_mode=2 参数 设置来避免，当然这样会导致自增不连续。
但是 uuid 导致的随机 IO 更有可能是并发效率降低。

[realpg]

@robot777 #4
我曾经用过这种 MYSQL 自增
总共生产环境 14 台 MYSQL 订单服务器 架构设计最多兼容 100 台分布式数据库服务器
每台自增的间隔是 100 BIGINT 类型
第一台数据库的第一条记录 ORDERID 为 1000001 自增间隔 100
第二台数据库的第一条记录 ORDERID 为 1000002 自增间隔 100
以此类推

每一台服务器的自增 ID 尾数均不相同


@nisekoi #17
内部用自增 ID 不代表显示给用户不经过简单变换，直接把数字 ID 暴露给用户只能说设计弱爆了
比如做一些不吃性能的简单变换法把数字变成字母或者变成另外一组数字

[iPhonePKAndroid]

隐藏业务数量

[derrickT]

自增通常来说应该作为 API 中的参数暴露，容易被遍历获取数据，但是性能好，索引效率高
UUID 没有什么规律，字符串，索引效率差，但是不会被遍历

[aborigine]

如果是 mysql，自增 id 做主键而且不要用到业务中吧！可以用 uuid 当作 user_id 之类的区分并设成 unique key。原因么，详见高性能 MySQL

[zhzer]

分布式无法自增或者说无法同步，就这点区别，干的事都一样

[Moorj]

我用 UUID

[abcbuzhiming]

@acr0ss uuid 想和自增 id 比插入快你是不是搞错了什么，uuid 保证的是分布式环境下的唯一性，轮性能别和自增 id 比

[abcbuzhiming]

@realpg 数字 id 暴露给用户也没啥，关键是要有完善的权限控制系统，数字 id 暴露了就出安全问题明显是设计缺陷

[realpg]

@abcbuzhiming #29
并不是，主要是对于自增系统，数字 ID 基本暴露订单量，增量，逻辑关系，对于有心人来说，这非常敏感

[abcbuzhiming]

@realpg 我很有兴趣，你说说看有心人就算知道了我的订单量和增量，它能干什么，这就好比公司营业额，你知道了又能做啥

[realpg]

@abcbuzhiming #31
我随便举点例子，实际上在有心人那里，能做的东西不止这些

比如你是一个正在吹牛逼拉 C 轮投资的电商，处处造势，日订单量千万，会员三亿，然后被媒体公开，你家 UID 才到九百多万，昨天下单订单号跟今天订单号就差六十多万，完事你家得用多钱去公关这些恶劣影响


商业企业，自身的数据是最值钱的商业机密之一，通过外部参数判断出你家的很多数据，是重要的数据泄露


你要说这些都没啥用，那再来个有实际应用的

公务员报名考试 120 元，很多人愿意花无数个 120 元，就为了摸报名人数

[abcbuzhiming]

@realpg 666666，果然多听听别人的脑洞对自己有帮助。我认同你的说法

[013231]

@realpg
@abcbuzhiming
這還真不是腦洞, 我碰到過幾乎一模一樣的事. 有人拿個項目來忽悠我們老闆, 然後我發現他的自增 UID 比他宣稱的用戶量少兩個數量級...

[acr0ss]

@abcbuzhiming

感谢指出错误

我只考虑了并发生成的时间，忽略了插入后重排索引的时间
看来没有诸位老哥了解的透彻，避免误导

[huadi]

@realpg 所以自增不能是纯自增。比如每天或者每 2 小时，增加 10000。当然这样有溢出风险，比如 2 小时内新增用户不能超过 10000

[realpg]

@huadi #36
我还是支持前台显示变换的方式
通过 view 层和取回参数时的简单变换

[buliugu]

自增的话可以用 Hashids 处理一下