比如一个 User 表 , 这唯一标识是用自增 ID,还是账号, 还是 UUID 呢.
我的话会想用自增 ID, 但面试官说用 UUID, 自增 ID 在大并发注册的时候会产生性能问题.
而我原先的项目架构是用账号的.
麻烦大佬解答下...
› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
This topic created in 2179 days ago, the information mentioned may be changed or developed.
 |
1
netnr Oct 16, 2020
业务系统，用 UUID ,更灵活，没保存前就拿到 ID，导入导出方便
|
 |
2
crystom Oct 16, 2020  1
注册用户都大并发那就太厉害了
|
 |
4
yrj Oct 16, 2020 via iPad
如果注册量大到连自增 id 都不行，那应该有专业 dba 去解决问题了。可以试试雪花算法
|
 |
5
opengps Oct 16, 2020 via Android
上来就自增 id 有性能问题，这思维局限也是没谁了。
反例：我 64 个库，每个库分别 1 ～ 63 设计，都 64 步长，分库自增还不够？那我来个 1024 个库共同完成呢？ |
 |
6
qa2080639 Oct 16, 2020 via Android
有多少个平台大到注册都得考虑高并发。果然是面试造火箭
|
 |
7
beidounanxizi Oct 16, 2020 1
面试官是 SX，uuid 会有性能问题 page split 去看看高性能 MySQL 吧
|
 |
8
mscststs Oct 16, 2020
user 表考虑并发的性能问题，你们是要给沙子编号吗？
|
 |
9
eric Oct 16, 2020
MySQL 不要用 UUID 当主键。
|
 |
10
hooopo Oct 16, 2020 via Android
面这种问题的面试官
|
 |
11
fiypig OP |
 |
13
Mitt Oct 16, 2020
自增 ID 再有性能问题也不适用于 User 表啊，User 都并发注册成这样了，考虑的就不是表的问题而是恶意注册了吧
|
 |
15
Leigg Oct 16, 2020 via Android
考虑这个问题也太极端了，多高的并发才会关注到这个性能影响？ uuid 作为主键的缺点楼主先查查，我怎么感觉你是个刚毕业学生？
|
 |
16
by73 Oct 16, 2020 1
UUID 确实不太适合作为主键，原因很简单，太长了。。另外如果是自增的话，在并发场景所有线程都需要同步访问上一个值，肯定会有性能损失的。
目前分布式的算法，一般都是基于时间戳，让每个线程不同步也能生成一个自增且概率上尽可能唯一的值。 |
 |
17
sapocaly Oct 16, 2020
屠龙的话:单独的 uuid service，cache 好按此 sharding，sharding table 就用 integer.
可以参考:https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c |
Select Language