mysql 主键用有序 uuid 还是 uuid_short 好，有没有明显缺陷？ 有序 UUID 通过这样实现 uuidtobin （ uuid()）。
› 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 2413 days ago, the information mentioned may be changed or developed.
11 replies • 2020-02-17 11:28:08 +08:00
 |
1
ebingtel Feb 16, 2020
如果不是分布式,还是整数好呀……
|
 |
3
opengps Feb 16, 2020  4
根据实际设计就好：
int 自增也不是不支持分布式，而是需要预留自增跨度，比如第一节点从 1 自增，自增步长为 32 （这里就意味着预留了 32 个数据库节点扩容空间） uuid 是否需要有序，重点在于写入性能，采用有序是为了保证落盘顺序为“尾部追加”，这时候如果使用了时间戳列作为聚集索引，那么 id 列是否就不需要使用有序了（优缺点：浪费一个索引的空间损失，但是 id 规则会简化） uuid_short 我没用过，大致感觉就是省了一部分索引占用的硬盘空间，查询时候也省了一点内存，会有一定的提升。 |
 |
4
qiyuey Feb 16, 2020
分布式生成 big int unsigned 的趋势递增 id 作为主键
|
 |
6
Aresxue Feb 16, 2020
分布式 id 为什么不用推特的 snow 算法生成，uuid 的缺点太明显了
|
 |
8
chenluo0429 Feb 16, 2020
@jry 可以自己决定时间戳占用的长度的，标准的是 32 个机房，每个机房 32 台机器，共 1024 台机器，每毫秒最多生成 4096 个 id，可以用 69 年。你每多挪出来 1bit，可用时间就翻一倍。
|
|
9
chenluo0429 Feb 16, 2020
@jry 雪花算法可以保证有效期内不会出现重复 id，但是存在时钟回拨的问题
|
Select Language