自增主键和UUID主键的优缺点及适用场景
我们首先考虑效率和存储空间,然后再考虑安全和分布式
使用自增主键
优点:
1、数据存储空间小
2、查询效率高
缺点:
1、如果数据量过大,会超出自增长的值范围
2、分布式存储的表操作,尤其是在合并的时候操作复杂
3、安全性低,因为是有规律的,如果恶意扒取用户信息会很容易,如果是单据编号使用,竞争对手会容易查询出货量
使用UUID主键
优点:
1、出现重复的机会少
2、适合大量数据的插入和更新操作,尤其是在高并发和分布式环境下
3、安全性较高
缺点:
1、存储空间大(16 byte),因此它将会占用更多的磁盘空间, MySQL官方有明确的建议主键要尽量越短越好,36个字符长度的UUID不符合要求
2、性能降低,对MySQL索引不利: 如果作为数据库主键,在InnoDB引擎下,UUID的无序性可能会引起数据位置频繁变动,严重影响性能。
适用场景
1、项目是单机版的,并且数据量比较大(百万级)时,用自增长的,此时最好能考虑下安全性,做些安全措施
2、项目是单机版的,并且数据量没那么大,对速度和存储要求不高时,用UUID
3、项目是分布式的,那么首选UUID,分布式一般对速度和存储要求不高
4、项目是分布式的,并且数据量达到千万级别可更高时,对速度和存储有要求时,可以用自增长。
分布式环境下保证主键的唯一性
目前两种解决方式,下面分别介绍:
Twitter-Snowflake 64位自增id算法
背景:
Twitter-Snowflake算法产生的背景相当简单,为了满足Twitter每秒上万条消息的请求,每条消息都必须分配一条唯一的id,这些id还需要一些大致的顺序(方便客户端排序),并且在分布式系统中不同机器产生的id必须不同
Snowflake算法核心
时间戳 + 工作机器id + 序列
Snowflake ID有64bits长 由如图4部分组成:
- 第一位不可用
- 第二组 timestamp—41bits 使用41位时间戳,精确到毫秒,意味着其可以表示长达
(2^41-1)/(1000360024*365)=139.5年
,另外使用者可以自己定义一个开始纪元(epoch),然后用(当前时间-开始纪元)算出time,这表示在time这个部分在140年的时间里是不会重复的,另外这里用time还有一个很重要的原因,就是可以直接更具time进行排序,对于twitter这种更新频繁的应用,时间排序就显得尤为重要了。 - machine id—10bits(工作机器id),该部分其实由datacenterId和workerId两部分组成,这两部分是在配置文件中指明的:
10位的数据机器位,可以部署在1024个节点,包括5位datacenterId和5位workerId
1、datacenterId,方便搭建多个生成uid的service,并保证uid不重复,比如在datacenter0将机器0,1,2组成了一个生成uid的service,而datacenter1此时也需要一个生成uid的service,从本中心获取uid显然是最快最方便的,那么它可以在自己中心搭建,只要保证datacenterId唯一。如