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

[kerb15]

比如：

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

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

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

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

[tairan2006]

无意义，自增或者 snowflake

MySQL 的话别用 uuid

[Mithril]

这么多人都没说到点子上。。
问题是 MD5 或者其它的摘要算法都是会冲突的啊。。。
算法设计目的是尽量阻止人为制造冲突，而不是完全没有冲突，毕竟只是摘要而已。小概率事件并不等同于不可能事件。
UUID 是直接在里面包含时间戳从而避免冲突的，你这个连时间戳都一块摘要了。。。
除非你自行设计了解决办法，不然完全不应该直接用 Hash 作为数据库主键。

[3dwelcome]

@Mithril 冲突可以切换到 64 位，128 位 hash，这种毕竟是少数，在一定数据量下属于可控范围，可以特殊处理。

[icegreen]

同意上面一位老哥的说法；
需要考虑你的数据库引擎以及索引结构， 以 mysql 的 innodb 来说， 主键无序，在插入的时候，会导致大量页分裂，降低索引效率；

[cheng6563]

非有序的主键对索引不太友好吧

[zchlwj]

MD5 可是会冲突的

[securityCoding]

不要把问题复杂化 , 直接使用雪花算法就行了

[Felldeadbird]

雪花算法可以满足楼主的需求了。

[ppyzzz]

@hbolive 老哥，你这个回复是我在所有评论里面最接近真相的

[tailf]

主键使用这么长的字符串，确实会影响性能

[lanterboy]

19L 正解，如果楼主用的是 InnoDB 引擎，主键是聚簇的，乱序主键非常影响性能，建议把主键和业务唯一键分开，主键可以用雪花

[inktiger]

占用空间是肯定的，问题复杂化了也是肯定的，做之前先想想目的是什么，我是觉得一切根据自身原因来

[tabris17]

hashids

https://hashids.org/

[rimutuyuan]

主键 id 不要动，新建 user_id 字段唯一索引就能满足

[jsq2627]

1. MySQL innodb 主键是聚族索引，用 uuid / md5() / base58 / base64 等生成的无序串做主键，数据量增长后插入性能急剧下降
2. 可以选择主键使用 AUTO_INCREMENT 整数，新增一列存储 uuid 等无序串并加索引。不过大查询量下，性能肯定不如主键这种聚族索引，可以通过缓存解决
3. uuid 也不完全是无序串，毕竟它是基于时间戳生成的，按一定规则进行解构重组，也能变得“有序”，作为主键据说性能也还行
https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
4. snowflake 完美解决了所有问题

[jsq2627]

至于用 md5 还是 uuid，楼主自己觉得开心请随意选择。只要保证没有冲突就好。君不见 b 站现在都用变种 base56 了

[jsq2627]

@jsq2627 * 变种 base58

[Heebe]

我想问下，MD5 是你想出来的，还是有人教你的？如果有人教你的，赶紧删除了他，因为他可能让你损失 1 个亿。

我猜楼主是想做成一个无法被人类读取的订单号，来防止别人猜测业务量？
这叫分布式 ID，随便搜索下就有一堆的方案。

[Mithril]

@3dwelcome 插入数据的时候主键重复了。。这怎么特殊处理。。

[Cmdhelp]

建议看一波 al 爪洼开发手册