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