MySQL内置函数uuid和uuid_short简析

有同学问到MySQL的uuid这个函数。简要介绍一下。
用法
简单看到,这个值,每次执行都是不同的。
生成规则
第1 2 3 段是与时间有关的。
  www.2cto.com  
time_low、time_mid、time_high_and_version转成16进制后分别对应第1 2 3段。这个时间是从1582-10-15 00:00:00.00到当前时间的100ns值。(实际上系统只能取到精确us,再乘以10)。所以你短时间连续执行的话,比较可能只有第一个值在改, 实际上1 2 3都可能会改变。
第4段是你启动这个MySQL后第一次执行select uuid()时的随机数,每次重启会改变。
第5段是mac值转过来的,同一个机器多实例的一般相同。如果mac值获取不到,则是一个随机值。
所以这个值可以认为是每次执行都不相同。并且不同实例之间也只有极微小概率重复。
Uuid_short
         与uuid返回固定长度字符串不同, uuid_short的返回值是一个unsigned long long类型。MySQL启动后第一次执行的值是通过server_id << 56 + server_start_time << 24来初始化。server_start_time单位是秒。 之后每次执行都加1。
         由于每次加1都会加全局mutex锁,因此多线程安全,可以当作sequence来用,只是初始值有点大。
Sequence
         MySQL没有Oracle那样的sequence,在不是很精确的情况下,可以考虑上面提到的uuid_short。有一些不足:  www.2cto.com
1、初始值太大,无法重设
2、存在一个问题是每次重启后第一次执行的值不是重启前的那个值+1
3、而且如果重启在1s内完成,可能出现不单调递增(虽然这个可能性微乎其微)。
         要满足上面的需求,可以考虑用udf实现。

关于全局唯一ID生成方法

唯一ID生成的主要目的是:为一个分布式系统的数据object产生一个唯一的标识。
一般对于唯一ID生成的要求主要这么几点:
  • 毫秒级的快速响应
  • 可用性强
  • prefix有连续性方便DB顺序存储
  • 体积小,8字节为佳
目前看到过的唯一ID生成方法主要有以下几种:
UUID:
优:java自带,好用。
劣:占用空间大
Snowflake: timestamp + work number + seq number
优:可用性强,速度快
劣:需要引入zookeeper 和独立的snowflake专用服务器
Flikr:基于int/bigint的自增
优:开发成本低
劣:如果需要高性能,需要专门一套MySQL集群只用于生成自增ID。可用性也不强
Instagram:41b ts + 13b shard id + 10b increment seq
优: 开发成本低
劣: 基于postgreSQL的存储过程,较为偏门