这是一个创建于 1750 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 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 就酸爽了 所以有的公司会不惜一次网络请求去专门去搞一个派号服务 |
 |
14
uxstone 2020-02-07 21:35:00 +08:00
|
|
15
uxstone 2020-02-07 21:35:33 +08:00
？？？ 不支持 Markdown?
|
Select Language