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

[kerb15]

比如：

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

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

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

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

[msg7086]

主键不与业务相关。你看看你的想法是否违反了这条惯例。

[xuanbg]

占空间倒没什么，现在存储这么便宜……

问题是：
1 、效率低，算一个哈希值也是有开销的。
2 、建立索引效率受影响。

然后，直接用 uuid 他不香吗？

[changePro]

@Jacky23333 会导致性能下降，如果缓存不命中，导致大量磁盘 IO 。因为相同的数据，page 更多了。buffer pool 设计好的话的话，其实也还好

[PopRain]

如果不想用 uuid, 推荐 Twitter 雪花(SnowFlake)算法，一个 64 位整数

[l3n641]

不建议这样做,主键越长 索引也占用空间.如果数据量大的话,添加和更新数据会很大影响性能.如果是 mysql 的 inodb 的话.其他的普通索引都会包含主键键值.这时候会更加占用空间.

[saulshao]

通常情况下，主键字段就选择单纯的整数 /大整数 /无符号整数就行。
凡是需要某种业务相关计算来"产生"主键值的动作，都是花费很高并且没什么收益的方案。

[yinzhili]

不建议。这样的订单号过长，且可读性几乎等于 0 。

[PHPer233]

一个简单的 id 让你搞得这么复杂

[yjxjn]

雪花算法不香么？

[yjxjn]

@kerb15 防止撞库。说人话的意思就是防止让人家穷举猜到了

[joooooker21]

单体应用可以用自增主键
分布式应用可以用雪花算法或 uuid

你说的这种方法没有意义且消耗资源

[xiangyuecn]

设计 ID 结构最核心的一点，我觉得应当是时间粗略有序，uuid 、hash 都达不到时间粗略有序，参考楼上的雪花算法

你希望你的 id 排序之后是毫无规律的随机排序（似乎会影响插入性能）， 还是按照插入顺序先后排序（也就是插入时间），普通自增 id 天然有序。id 里面用时间因子作为前缀妥妥的，后面随便拼上 uuid 、md5 之类的，就基本上时间粗略有序了

[silvernoo]

md5 不是 128 位吗

[Jacky23333]

@changePro 我是说你这句话 “-“md5 生成的 userId 对索引不友好” 少误导其他人”

[Jacky23333]

@Jacky23333 我没觉得这句话误导他人了啊

[jugelizi]

似乎是 php 程序员

[aflow]

你这是在给后面埋坑，单体自增主键就好，md5 有重复的可能，不应该用来做唯一 id 。
不要自作聪明

[v2Geeker]

自增 id 好，这样建立的索引占用空间小，维护索引成本低，速度更快！

[dallaslu]

用户名 [e-mail] 密码 forecast
用户名 [e-mail] 密码 recast

所以还是乖乖用 UUID 吧。

另外，自增 id 和 UUID 可以同时用。主键自增，UUID 唯一约束。对外想用哪个就用哪个。

索引和存储空间的问题真不用担心。用户表邮箱、手机、用户名都有唯一约束，多一个也不见得会满。至于空间问题，最便宜的就是存储了……

[n0tyet]

把高性能 mysql 看完再继续思考