数据库主键是自增好还是UUID好,分布式环境下如何保证主键的唯一性

自增主键和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唯一。如