怎样选择 uid 生成策略?

[honmaple]

我想问一下大家的 uid 是怎么生成的,uuid 有 32 位太长,目前的策略是时间戳+用户 ID+两位随机数

def make_uid():
    a = str(int(time()))
    b = str(1).zfill(6)
    c = str(randint(10, 99))
    return a + b + c
a = make_uid()
print(a)

但看了一下,有 18 位,感觉还是有些长,那么如何生成 10 位以内的不重复 uid 呢?

[ZGLHHH]

uid 不是 user id 吗?我选择 MySQL 自增

[honmaple]

额， uid 不是 url id 吗,假设不用自增 ID

[Ouyangan]

一般使用 uuid,你提出这个问题的出发点在哪里，短了对你有什么帮助

[hxsf]

写过一个短网址服务，一下是我的策略
短网址说白了就是 k-v 。

默认生成 key 长度为 6 ，然后查重，重复就长度+1 再生成，再重复再+1 。直到不重复。

方法虽然 low ，但是可以确保不重复且始终有解。

[misaka19000]

搭个车问下类似于 V 站的这种 284656 是如何生成的？有没有知道的能解释下

[YUX]

uid 不是 unique ID 嘛

[murmur]

@misaka19000 自增主键吧？

[SourceMan]

你们想把你们公司对外宣传几千万用户，然而只有 10 多万而已的事实通过自增主键暴露出来吗

[popu111]

@SourceMan
最滑稽的是碰到过一家 IDC 把用户 ID 弄大了 2w 然而忘了订单 ID 。。。

[Syc]

DES[Base64[(MD5 加盐(SHA1(时间戳+用户 ID+随机数)))+随机数+随机数]]

[chineselittleboy]

不是不能用自增的嘛

[eliteYang]

看下 snowflake 算法，比较适合你

[murmur]

@chineselittleboy 为什么不能自增 老用户 id 号短那是身份象征

[fy]

我自用的 ObjectID 生成
https://github.com/fy0/my-object-id

[fy]

不过长度这种东西就没办法了

[honmaple]

@Ouyangan 主要看到有说 uid 太长的话，对于 select 或者建立索引效率上有很大的影响

[honmaple]

@YUX 额,好吧

[honmaple]

@hxsf 每次都查重有些太繁琐了

[ethego]

@honmaple 无稽之谈

[honmaple]

@eliteYang @fy OK,我参考一下

[honmaple]

@ethego 能解释一下吗

[Syc]

@honmaple 只要把索引和缓存做好没有什么是不可能的。

[ethego]

@honmaple https://www.percona.com/blog/2007/03/13/to-uuid-or-not-to-uuid/

[zhangxiao]

@honmaple 如果你目前 18 位是 base 10 的可以生成后转 base 36

[ihuotui]

参考淘宝订单 id 规则。哈哈。

[hxsf]

r#18 @honmaple 唯一一种可以在信息量减少的条件下保证不重复的办法就是查重。。。

[tabris17]

自增 ID + Skip32 加密

[zzzhan]

优雅简洁地实现短 ID http://www.jianshu.com/p/ee469e1e1f9d

[honmaple]

@ethego Thank you,正在研读

[honmaple]

@zhangxiao @ihuotui @tabris17 @zzzhan Thank you

[julyclyde]

我们公司早年是预先生成一堆，在一个单独保存 uid 的表里
用的时候取一个出来

[jsq2627]

@honmaple
@ethego
在数据库中应用 UUID/GUID 要关注是否为 primary key 的问题。
很多数据库系统是把 primary key 作为 clustered index 的， UUID/GUID 这类比较长的 ID 不适合作为 clustered index ，但是很适合作为 primary key 。
如果数据库系统支持 clustered index 和 primary key 分离定义的话，应该用 UUID/GUID 列作为 primary key ， auto increment 列作为 clustered index ，如果不支持分离，那最好还是别用 UUID/GUID 作为 primary key 。

[ethego]

@jsq2627 http://inessential.com/2014/04/15/more_on_uuids_and_clustered_indexes 有一定的道理，但是不要盲目优化，确定 uuid 真的在当前业务下会引起足够的性能损失再做决定。

[ryd994]

谁说 uuid 比 20 位字符长的？
uuid 是 128 位整数， 32 位 hex 字符
128 vs 32*8=256

mysql 官方文档： http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html#function_uuid
“ UUID() returns a value that conforms to UUID version 1 as described in RFC 4122. The value is a 128-bit number represented as a utf8 string of five hexadecimal numbers in aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee format ”

[9hills]

没有 32B ，如果使用常用字符表示的话， uuid 20B 足够了，毕竟只有 128bit

[julyclyde]

@jsq2627 说的很对， clustered index 很重要

[breeswish]

直接 uuid 呀

[practicer]

我们公司用于跟踪用户行为的"uid"是 32 位长。能不能直接用标准库里的 hashlib 呢？
import hashlib
m = hashlib.md5()
m.update('Obama')
m.hexdigest()