2020 年了，还有人觉得 UUID 比 int 适合“海量”数据？
这是一个创建于 2148 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 2020-02-07 10:52:17 +08:00
=== 2.7 ===
看到评论有提到业务场景，我补充一下。
本人是家初创的小白，昨晚主管让我传枚举类数据的时候用 code 而不是 name，因为“int 比 string 小，省流量”。。。！@#￥%……
我一时间不知道该吐槽这个需求还是吐槽这个动机，只是突然想起我们许多业务表的主键是 uuid。当时设计数据库的时候我就提过以我们的业务量（能不能撑到天使都不知道。。。）和单机架构，不需要每个表都用 uuid，毕竟 36 位的长度摆在那里。奈何人微言轻。
（小声逼逼：主管是海归，MS 技术栈，无分布式经验）
=== 生活的分割线 ===
与其说是技术讨论，其实是辛酸生活的吐槽。
祝各位在家办公愉快。
看到评论有提到业务场景，我补充一下。
本人是家初创的小白，昨晚主管让我传枚举类数据的时候用 code 而不是 name，因为“int 比 string 小，省流量”。。。！@#￥%……
我一时间不知道该吐槽这个需求还是吐槽这个动机，只是突然想起我们许多业务表的主键是 uuid。当时设计数据库的时候我就提过以我们的业务量（能不能撑到天使都不知道。。。）和单机架构，不需要每个表都用 uuid，毕竟 36 位的长度摆在那里。奈何人微言轻。
（小声逼逼：主管是海归，MS 技术栈，无分布式经验）
=== 生活的分割线 ===
与其说是技术讨论，其实是辛酸生活的吐槽。
祝各位在家办公愉快。
 | 1 murmur 2020-02-06 19:35:47 +08:00 uuid 和 int 有本质区别么，多组的 int 按十六进制表示不就成了 uuid，很多是为了分布式唯一留的余量，没办法么，同步不过来就得把差距拉大省着冲突 |
 | 2 opengps 2020-02-06 20:56:18 +08:00 via Android 单看容量，确实更合适 |
 | 3 cmdOptionKana 2020-02-06 21:01:41 +08:00 “海量”还打了双引号，意思是数量不多，还是强调真的很大量？ int 够用吗？ |
 | 4 GM 2020-02-06 21:13:22 +08:00 @cmdOptionKana int64 最大大小为 9223372036854775807，每天消耗一万亿个，能消耗 9,223,372 天，也就是 25,269 年 |
 | 5 whywhywhy 2020-02-06 22:38:07 +08:00 via Android 我们以前的系统是这样 字段 1，guid，字段 2，1/0 程序设计的也傻，一次读取一大摞，然后就看到网络被长时间占用，界面卡卡卡。。。（异地办公，带宽很小） 那时候就想，要是用 int 是多好啊 |
| 6 opengps 2020-02-06 22:49:58 +08:00 via Android 我当年为了避免系统有上限，选择了无主键 |
 | 7 Mithril 2020-02-06 22:58:43 +08:00 @opengps 然而发现这么多年也没用到 int 上限？ 其实你要做分布式的话，UUID 就比 int 好啊。如果只是单一数据库，那直接 int64 就完了。 |
 | 8 blless 2020-02-06 23:08:59 +08:00 ？数据库的话不是自增主键跟 uuid 的讨论吗？ int 如果全局唯一了 实质上也是一种 UUID。跟自增主键有个屁关系。 |
 | 9 akira 2020-02-07 00:53:05 +08:00 然而就算用 uuid 做业务主键，我还是喜欢在前面加一个自增主键 |
 | 10 Jacky23333 2020-02-07 01:09:21 +08:00 via Android  1 uuid 做主键性能不会有问题吗.... |
 | 11 wysnylc 2020-02-07 05:33:53 +08:00 via Android 分库没法用自增主键，拉倒吧 |
 | 12 gabon 2020-02-07 08:36:51 +08:00 via Android 不考虑业务场景跟这儿扯淡呢 |
 | 13 lshero 2020-02-07 11:09:42 +08:00 uuid 的索引不好搞 int64 遇到了 JS 就酸爽了 所以有的公司会不惜一次网络请求去专门去搞一个派号服务 |
 | 15 uxstone 2020-02-07 21:35:33 +08:00 ？？？ 不支持 Markdown? |
Select Language