数据库表中唯一主键 id 用 32 位的 md5 算出来的值是否可行？

[kerb15]

比如：

用户表中，将用户邮箱+密码的值去做 MD5，得出来的值作为 userId

订单表中，将订单数据+时间戳的值去做 MD5，得出来的值作为订单 Id

主要的疑问是，32 位的 id 是否过于占用空间？

以及其他缺点希望各位 V 友能发表下看法。

[Takamine]

……这样做的意义是什么，强行想让主键 id 和业务含义关联起来吗。

[ajaxfunction]

要是用户密码改了呢？ 之前生成的 userid 和现在的 userid 不一样，系统不就乱了吗？
简单的问题复杂化了啊！

[creedowl]

要是用户改密码怎么办，如果是想要隐藏真实 id 可以用 hashid
订单可以用雪花算法

[hbolive]

@Takamine 这样的 id 看起来很酷。。

[nvkou]

uuid 也是这么做的。只不过人家用一去不回头的时间做种子之一。
没有必要重复发明轮子

[kerb15]

@Takamine
@ajaxfunction
@creedowl
只是想简单的生成一个唯一 id 而已，用户改密码没什么影响，id 还是那个 id

[luopengfei14]

用户一旦修改邮箱、密码，你就找不回来 userId，而且 md5 生成的 userId 对索引不友好。
简单点直接用自增 id 当作 userId，考虑多的可以用雪花算法生成 userId，一般够用。

还有 md5 、uuid 字符串理论上避免不了重复的可能

[yukiloh]

用户登陆用账号行不,手机行不,你要做 3 个 userid 吗

[kerb15]

@nvkou 倒也没有说想重复造轮子，不过确实没有想过直接调用已有的算法去生成，是个不错的方式

[chendy]

负载不大自增就够用了
至于 “32 位过于占用空间？”…emm ？？？

[kerb15]

好吧，我的表达存在歧义，其实这个 userid 并不作为对外公开的值，也不提供给用户登录使用，只是内部对用户的一个标识，可以理解为就是用户表的主键 id

[murmur]

uuid 也比 md5 好啊，你的用户量多少，少的话可以，多的话得考虑下防装，你估计是看了 mongo 那个主键，别人是有算法的，可以保证在数据结构上的一些优化

[murmur]

@Takamine 有些业务需要随机化主键，否则破解你一个接口 id 直接递增数据就爬一遍了

[kerb15]

@murmur 想请教一下防装是什么意思

[linvon]

@kerb15 防撞吧

[changePro]

“md5 生成的 userId 对索引不友好” 少误导其他人

[wangyzj]

不是不行, 百害无一利

[changePro]

首先，为什么要这样做？主键 ID 几乎都是 fixed length，磁盘内存、又便宜，索引不是问题。md5 也可以看作是 UUID，用 UUID 做主键大部分是为了解决分布式的一些问题，题主是为了折腾？

[Jacky23333]

你这样做会严重影响插入性能，因为会频繁导致页分裂跟行移动，产生空间碎片

[Jacky23333]

@changePro 我觉得没毛病啊