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 
这是一个创建于 1824 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如一个 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 |
Select Language