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

[kerb15]

比如：

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

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

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

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

[3dwelcome]

@Mithril 主键重复，就对自身加盐 hash，变成第二个，第三个 hash，循环多试几次，最后总能插进去的。
查询也是同样操作，查出来数据需要二次校对，如果订单不对就进行二次 /三次查询。

当然这些都是有前提的，表数据量必须在可控范围内。万一数据一多，冲突越多，肯定没戏。

[sujin190]

id 的话，感觉有顺序的更好一点吧，空间的感觉无所谓吧，反正内存磁盘也不值钱

[Mithril]

@3dwelcome 你这个前提是他不拿主键直接做查询，关键是既然不查询那为啥不直接自增 id 。。。
而且冲突就只是个概率，并不是真的可控，只是大概率不出问题。运气不好一直冲突也不是没可能的。

[3dwelcome]

@Mithril 我也不知道楼主为啥放着自增长 ID 不用，要另辟蹊径。也许就是楼上有人猜测的，防止对数据库暴力查询。因为实在想不出，这样做有别的什么理由。
至于谈到冲突，以前测试过对 MD5 的散列分布图，图上来看还是挺均匀的。

[cloudzhou]

如果不使用自增 id 的话，uuid 不行吗？ snowflake 也可以

[jasonding]

已经确认存在两个不同的值经过 MD5 运算后可能会导致结果一致，万一不幸碰上了你准备怎么处理