比如一个 User 表 , 这唯一标识是用自增 ID,还是账号, 还是 UUID 呢.
我的话会想用自增 ID, 但面试官说用 UUID, 自增 ID 在大并发注册的时候会产生性能问题.
而我原先的项目架构是用账号的.
麻烦大佬解答下...
1
netnr 2020-10-16 20:57:43 +08:00
业务系统,用 UUID ,更灵活,没保存前就拿到 ID,导入导出方便
|
2
crystom 2020-10-16 20:58:24 +08:00 1
注册用户都大并发那就太厉害了
|
4
yrj 2020-10-16 21:33:31 +08:00 via iPad
如果注册量大到连自增 id 都不行,那应该有专业 dba 去解决问题了。可以试试雪花算法
|
5
opengps 2020-10-16 21:37:44 +08:00 via Android
上来就自增 id 有性能问题,这思维局限也是没谁了。
反例:我 64 个库,每个库分别 1 ~ 63 设计,都 64 步长,分库自增还不够?那我来个 1024 个库共同完成呢? |
6
qa2080639 2020-10-16 21:38:31 +08:00 via Android
有多少个平台大到注册都得考虑高并发。果然是面试造火箭
|
7
beidounanxizi 2020-10-16 21:51:22 +08:00 1
面试官是 SX,uuid 会有性能问题 page split 去看看高性能 MySQL 吧
|
8
mscststs 2020-10-16 22:19:14 +08:00
user 表考虑并发的性能问题,你们是要给沙子编号吗?
|
9
eric 2020-10-16 22:29:22 +08:00
MySQL 不要用 UUID 当主键。
|
10
hooopo 2020-10-16 22:36:49 +08:00 via Android
面这种问题的面试官
|
11
fiypig OP |
13
Mitt 2020-10-16 22:48:49 +08:00
自增 ID 再有性能问题也不适用于 User 表啊,User 都并发注册成这样了,考虑的就不是表的问题而是恶意注册了吧
|
15
Leigg 2020-10-16 23:35:30 +08:00 via Android
考虑这个问题也太极端了,多高的并发才会关注到这个性能影响? uuid 作为主键的缺点楼主先查查,我怎么感觉你是个刚毕业学生?
|
16
by73 2020-10-16 23:40:12 +08:00 1
UUID 确实不太适合作为主键,原因很简单,太长了。。另外如果是自增的话,在并发场景所有线程都需要同步访问上一个值,肯定会有性能损失的。
目前分布式的算法,一般都是基于时间戳,让每个线程不同步也能生成一个自增且概率上尽可能唯一的值。 |
17
sapocaly 2020-10-16 23:43:10 +08:00
屠龙的话:单独的 uuid service,cache 好按此 sharding,sharding table 就用 integer.
可以参考:https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c |