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

[Geekerstar]

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

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

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

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

[chendy]

遇到因为字符串 id 导致的严重性能问题了么？没有的话无所谓，有的话……
下划线就下划线，反正都有名称转换的配置去做这些事情

[xupefei]

字符串有什么问题，为啥要改

[chinvo]

数据库和 json 用蛇式不是很正常么...

字符串 id 不是性能瓶颈就没必要动. 实在要动可以停机维护改成 binary(16) 类型.

[9yu]

凭什么要听你的改？

[mreasonyang]

数这么设计虽然很多人会说索引性能有问题，但其实大部分场景都遇不到所以还好，真正问题比较大的是你们用的这个 uuid 生成方案是不是可靠。

另外数据库字段一般都是推荐用下划线分割，主要是为了避免忽略大小写等暗坑，当然这个还是要看你们的编码规范是怎么定的。

[shiji]

1，这样的主键没毛病，我也觉得不会产生多少性能问题。

2，尊重现有的命名方式吧，现在才想改太晚了，劳民伤财。

[xiangyuecn]

无聊的需求🐶 程序只要能跑，跟代码美观不美观 符不符合你的规范没有任何关系

[ericbize]

1. 不要一厢情愿的去改，数据库卡就卡啊，管你开发什么事情呢

2. 你要看这个 id 涉及到的面有多广，不然你改了，不行，你再改回来，数据不一致，或者有新插入数据，你人都傻。

3. 给你个不成熟的思路， 新建一个表 用 bigint 做主键，然后把 你现在这个表弄过去（就等于加了一个 int 的主键，然后原有的字段保留，只是把 主键改到 int 去），最后再 rename 。（可能途中会涉及到 表停用，之类的问题，自己要在测试环境 和 dba 一起跑通测试，不要直接拿线上去搞，不然你跑路都不好跑！！！ ）

[cweijan]

mysql 主键就是一种索引, 所以如果数据量不大, 根本无需担心性能问题.
数据库字段用下划线没什么毛病, 实体类用下划线确实不太好, 看你能不能说服项目负责人.

[namelosw]

UUID 不考虑性能其实还挺好用的，ID 是有状态的，UUID 是无状态的。

比如你写一个麦当劳的取餐号，四五位的你就要考虑碰撞所以就要记录发出去那些，收回哪些，不小心就容易出 bug，UUID 的话就当他不碰撞就好了，所以什么也不用记。只是人看 UUID 眼晕，但是机器不会眼晕。

而且一般应用其实都用不上这点极限优化，总有远比这个值得优化的地方。

[roundgis]

uuid 有什麼問題？

[iyaozhen]

uuid 没问题呀，单查询的话

实体接收也用下划线，这个也还行吧，其实这样也好。编程规范核心是统一，如果涉及数据库、json 的都用下划线，其它 java 本身用驼峰，挺好的呀，只要不是混着来

[akira]

线上好好跑着的东西，为啥要去动他呢。。就因为你看着不习惯么。。
是性能出问题了 还是维护成本过大了？ 总要有点理由的啊。。

[shintendo]

还是工作不饱和

[anaf]

我现在做的项目一些表就是 UUID 目前没发现什么缺点 主要是用户表 商品表 店铺表等一些用户 其他一些 比如 分类 还是 int 自增

[james2013]

楼主还是太年轻,老项目能够正常运行就不要再大改了
大改没什么收益,大改出现问题,谁负责呢
自己负责的模块下,自己尽量写好就好了
除非楼主是 CTO，部门经理,架构师等职务，可以决定项目重构和统一项目

[levon]

我怎么觉得数据库用 uuid 做主键才是正道

[cubecube]

@levon 最好的是自增主键，uuid 会导致数据存储局部性差，相对来说查询性能是有影响的，哪怕是有索引也会导致过多的读操作。
uuid 也有好处，分布均匀，某些情况下写性能还行。

[levon]

@cubecube 自增主键诸多烦恼，比如你有个订单 id=1234，那么你就可以猜测可能有个订单 id=1235，这时候如果不控制的话，就可能可以打开别人的订单信息。如果是 uuid 则没有这样的问题。
另外有时会添加记录，先知道 id 也会带来很多方便，不用等写入数据库再返回 id 才能用。

[opengps]

既然是老项目，那么就继续照老的来吧，不建议修改