8
MySQL 数据库主键用了字符串的 UUID 怎么办？
source link: https://www.v2ex.com/t/799982
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
最近参与到一个老项目中：
MySQL 数据库主键 id varchar 64，如 00cfad279bf14e60a9c39c91e7dd8770
这种还有救么？？目前系统线上运行着，不太可能停掉来修改，有没有什么好的优化办法呢？
另外，这是个 Java 项目，数据库字段下划线，实体接收也用下划线，没有用驼峰，看着不习惯，用什么理由能劝说大家用驼峰呢。。。
14 条回复 • 2021-09-05 21:40:02 +08:00
mreasonyang 4 小时 26 分钟前 via iPhone
数这么设计虽然很多人会说索引性能有问题，但其实大部分场景都遇不到所以还好，真正问题比较大的是你们用的这个 uuid 生成方案是不是可靠。
另外数据库字段一般都是推荐用下划线分割，主要是为了避免忽略大小写等暗坑，当然这个还是要看你们的编码规范是怎么定的。
另外数据库字段一般都是推荐用下划线分割，主要是为了避免忽略大小写等暗坑，当然这个还是要看你们的编码规范是怎么定的。
ericbize 2 小时 57 分钟前
1. 不要一厢情愿的去改，数据库卡就卡啊，管你开发什么事情呢
2. 你要看这个 id 涉及到的面有多广，不然你改了，不行，你再改回来，数据不一致，或者有新插入数据，你人都傻。
3. 给你个不成熟的思路， 新建一个表 用 bigint 做主键，然后把 你现在这个表弄过去（就等于加了一个 int 的主键，然后原有的字段保留，只是把 主键改到 int 去），最后再 rename 。（可能途中会涉及到 表停用，之类的问题，自己要在测试环境 和 dba 一起跑通测试，不要直接拿线上去搞，不然你跑路都不好跑！！！ ）
2. 你要看这个 id 涉及到的面有多广，不然你改了，不行，你再改回来，数据不一致，或者有新插入数据，你人都傻。
3. 给你个不成熟的思路， 新建一个表 用 bigint 做主键，然后把 你现在这个表弄过去（就等于加了一个 int 的主键，然后原有的字段保留，只是把 主键改到 int 去），最后再 rename 。（可能途中会涉及到 表停用，之类的问题，自己要在测试环境 和 dba 一起跑通测试，不要直接拿线上去搞，不然你跑路都不好跑！！！ ）
cweijan 2 小时 34 分钟前
mysql 主键就是一种索引, 所以如果数据量不大, 根本无需担心性能问题.
数据库字段用下划线没什么毛病, 实体类用下划线确实不太好, 看你能不能说服项目负责人.
数据库字段用下划线没什么毛病, 实体类用下划线确实不太好, 看你能不能说服项目负责人.
namelosw 1 小时 31 分钟前
UUID 不考虑性能其实还挺好用的，ID 是有状态的，UUID 是无状态的。
比如你写一个麦当劳的取餐号，四五位的你就要考虑碰撞所以就要记录发出去那些，收回哪些，不小心就容易出 bug，UUID 的话就当他不碰撞就好了，所以什么也不用记。只是人看 UUID 眼晕，但是机器不会眼晕。
而且一般应用其实都用不上这点极限优化，总有远比这个值得优化的地方。
比如你写一个麦当劳的取餐号，四五位的你就要考虑碰撞所以就要记录发出去那些，收回哪些，不小心就容易出 bug，UUID 的话就当他不碰撞就好了，所以什么也不用记。只是人看 UUID 眼晕，但是机器不会眼晕。
而且一般应用其实都用不上这点极限优化，总有远比这个值得优化的地方。
iyaozhen 1 小时 15 分钟前
uuid 没问题呀，单查询的话
实体接收也用下划线，这个也还行吧，其实这样也好。编程规范核心是统一，如果涉及数据库、json 的都用下划线，其它 java 本身用驼峰，挺好的呀，只要不是混着来
实体接收也用下划线，这个也还行吧，其实这样也好。编程规范核心是统一，如果涉及数据库、json 的都用下划线，其它 java 本身用驼峰，挺好的呀，只要不是混着来
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK