MySQL 数据库主键用了字符串的 UUID 怎么办?

2021-09-05 17:16:36 +08:00
 Geekerstar

最近参与到一个老项目中:

MySQL 数据库主键 id varchar 64,如 00cfad279bf14e60a9c39c91e7dd8770

这种还有救么??目前系统线上运行着,不太可能停掉来修改,有没有什么好的优化办法呢?

另外,这是个 Java 项目,数据库字段下划线,实体接收也用下划线,没有用驼峰,看着不习惯,用什么理由能劝说大家用驼峰呢。。。

8688 次点击
所在节点    MySQL
79 条回复
cco
2021-09-06 09:39:34 +08:00
能跑就行,你再怎么规范,最终的结果也是在屎上上接着拉。
zealinux
2021-09-06 09:48:17 +08:00
一直都是 INT ID 改成 UUID 的,
从来没有见过 UUID 改回 INT ID 的。
pkoukk
2021-09-06 09:50:58 +08:00
@securityCoding 大家都说了数据量不大的情况啊。
那请问你觉得的在数据量不大的情况下有啥影响?
levon
2021-09-06 09:52:29 +08:00
@cubecube 至于性能问题,你的数据库能大过 youtube,amazon 吗,他们也是一样以字符串作为主键
lasuar
2021-09-06 09:54:33 +08:00
能够在你任职期间稳定运行 就够了,不要自己找麻烦。
myd
2021-09-06 09:56:48 +08:00
确实,这点性能损失无关紧要。

在性能方面,uuid 的缺点:
1. 比 INT 占用更多的存储空间;
2. 如果插入的 uuid 不是单调递、递减的,数据页会留出一部分空隙,导致存储占用进一步加大;
3. 各个页面(基本上)是非连续存储的,每个页面存储的记录数又变少,查找性能下降。
4. 添加的二级索引也有上面的问题。

总结:占用更多存储,性能略微下降。
wolfie
2021-09-06 10:01:06 +08:00
@cedoo22 #32
支付宝交电费 生成的 订单 ID 就是能看到规律的数字。

@zealinux #42
因为有强迫症的空降老领导。
zealinux
2021-09-06 10:04:09 +08:00
@wolfie
那个订单 ID 是业务 ID (对用户可见),
肯定不是 DB 的数据记录 ID
chengyiqun
2021-09-06 10:09:22 +08:00
@zealinux uuid 最大的问题就是, 当数据量大的时候, 写入会造成索引重排很浪费性能, 还有破坏了数据局部性, 也会导致损失点性能. int id 的性能是比 uuid 好的, 这个是共识吧. 所以才有类似雪花算法的出现
aliveyang
2021-09-06 10:16:48 +08:00
收益经得起付出么?不然改它干嘛,能跑就行
lap510200
2021-09-06 10:23:54 +08:00
@zealinux 正常来说 int 足够了,遇到过一些老项目用 uuid 多,主要都是为分表分库准备的,以前的机器配置和 mysql 性能在单表上不够,常常需要分表分库,但是现在很多都用 rds,固态+mariadb 普及,索引优化好,单表上亿数据都不慢
lizuoqiang
2021-09-06 10:25:28 +08:00
@levon 逗比,一口一个 youtube,amazon,咋滴他们数据库你设计的?还是说你看到过他们表结构了??
谁让你用自增 id 做订单号了??
主键 id 只是用作关系关联,用来做业务字段你怕是个 2b
wolfie
2021-09-06 10:29:53 +08:00
@zealinux #48
真就嘴硬,snowflake 这类 id 生成规则可控懂吗?

搜订单 id,看是 string 还是 int64 。
https://open.oceanengine.com/doc/index.html?key=ad&type=api&id=1696710607541263
RyanOne
2021-09-06 10:31:28 +08:00
1.uuid 占用空间大,同样的空间能存放 int 或者 bigint 的值更多,索引能更多的加载到内存中,查询效率更高
2.mysql 插入主键,强制会进行排列,从小到大排列,如果你插入的不是自增,那么 mysql 还需要额外做排列操作(比如节点分裂,树平衡操作等)
3.自增查找效率更高,因为如果要查询范围的,那么如果是自增的,只需要找到最开始和结束即可,如果不是自增,那么你找到的最后一个根本不知道是不是最后,还需要扫描节点
shenjinpeng
2021-09-06 10:37:31 +08:00
uuid 对性能的影响微乎其微, 将来负载均衡 集群 分表, 读写分离, 也很容易做 .
8.0 之前自增值可能会存在回溯问题 .
liuzhihang
2021-09-06 10:45:58 +08:00
前段时间刚好遇到这个问题,这边不是 UUID,是使用了别的订单号作为唯一索引(老系统),随着数据量的增多,开始很卡。这时候考虑对流水归档。

新表仅保留一个月数据,新增了 ID 列当自增主键,之前的流水号就还是唯一索引。

判断唯一的时候就得多表判断了,业务控制。

1. UUID 换成唯一索引,新增自增主键列。
2.看 SQL 如何写的
3. 数据量小就无所谓了
4. 影响这个我了解不多,都是看的资料,聚簇索引,叶子节点是双向链表,UUID,会插入到中间,造成页分裂,自增主键是持续往后添加,再往深了讲那就需要专业人士回答了。
keepeye
2021-09-06 10:46:13 +08:00
盲猜 大概字符串索引比较耗内存
8355
2021-09-06 10:57:58 +08:00
我觉得你可能只是觉得不习惯吧.代码并没有跑不动... 收益大还是雷大
hhjswf
2021-09-06 11:14:46 +08:00
mysql b+树怎么建立 uuid 这种乱七八糟的索引。。。
jswh
2021-09-06 11:15:06 +08:00
除了强迫症,其实一般没事得。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/799982

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX