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

[Geekerstar]

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

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

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

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

[xuanbg]

uuid 的性能问题主要体现在插入数据上面，查询基本没啥问题。数据量不大的情况下，uuid 简直完美。折腾他干啥呢

[imycc]

数据量大不大，不大的话对性能也没啥影响吧。
拿 uuid 做主键也是有好处的，要不你再结合一下业务的场景看看，是不是故意这么设计的？
如果对开发效率和系统效率有明显影响，不建议动，动了也没好处。。

[ccagml]

@chendy

[ccagml]

@chendyi3,3

[ccagml]

@chendy 发错了

[zt5b79527]

请教一下，uuid 不是有可能会重复么，怎么都没见大家提这个

[gouki]

@levon #19 正解 。而且。。。事务的时候。主键 ID 其实会丢，到时候更烦人。UUID 除了看数据的时候不直观，其他应该都是推荐。毕竟分库分表的时候，根本不用考虑重复（看生成规则
）

[aragakiyuii]

varchar(64) 是认真的？没救了，祈祷一下表不会太大
mysql 里 uuid 作主键的问题看这些
https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-performance-lets-discuss/
https://dba.stackexchange.com/questions/115766/should-i-use-uuid-as-well-as-id

除了数据库，java 生态里默认都是驼峰吧。。当然可以自己转成蛇形。感觉很难劝说，要改大家都得改，况且主键都能用 varchar64 。。估计还有其他一堆问题吧

[aragakiyuii]

@zt52875287 #25 正常使用 version4 能重复的话感觉可以去买彩票。。

[aragakiyuii]

@levon #19 递增主键这种场景下单号应该是独立的字段

[cpstar]

正如 5#所说，只要 UUID （其实你这个不能算是 UUID ）生成没有碰撞，那是没有问题的。唯一有问题的恰恰是你关于数字的强迫症。

编码拼写标准，完全就是规范，你没有话语权，那就是那句话：改变不了社会，就接受社会。

[cedoo22]

uuid 才是大部分系统的 ID 吧，递增这种 ID 如果需要暴露给 api 的话，容易被人吐槽

[cheng6563]

UUID 确实不太好，用带时间戳前缀的 UUID 比较好。

[securityCoding]

说没事的同学是不是没有了解过索引数据结构

[penll]

@levon 这种情况，一般订单号是独立一个字段，根据特俗规则生成的。
许多情况下，id 都不是直接暴露给前端，比如你为了不让外部自增遍历你的信息，都是用另一个生成的标识来作为该信息的唯一标识，比如 uuid(guid)；

[lucays]

数据量不大的话无所谓吧，这点性能损失没必要优化

[levon]

@aragakiyuii 你的表再大，有 youtube 的表大吗，人家也是字符串类型做主键的
@penll 不要这么死脑筋好不好，我只是举个订单作为例子而已。
”另一个生成的标识来作为该信息的唯一标识，比如 uuid(guid)；“这只是自欺欺人罢了

[forbreak]

@zt52875287 因为跟中彩票一样，你根本不可能中。uuid 也只是理论存在重复，实际基本遇不到。

[xLight]

除了你看着不舒服，你能说出哪些理由要搞？

[Asuka0947]

改出问题了你就会发现有人会把以前未发现的遗留问题一并甩给你，这时候就难办了。