Mysql数据库自增id、uuid与雪花id实例分析(id,mysql,uuid,开发技术)

概念介绍

三种主键

自增id ：1 2 3 4 5……

uuid ：UUID是Universally Unique Identifier的缩写，它是在一定的范围内（从特定的名字空间到全球）唯一的机器生成的标识符。通用唯一标识符的意思，可以以业务实际user id为主键 比如QQ号 手机号等

雪花id ：相比UUID无序生成的id而言,雪花算法是有序的（有时间参数）,而且都是由数字组成。雪花id最大为64位,符合java中long的长度64位。适用于大规模分布式

聚簇索引与非聚簇索引

自增id

自增的主键的值是顺序的,所以Innodb把每一条记录都存储在一条记录的后面。当达到页面的最大填充因子时候(innodb默认的最大填充因子是页大小的15/16,会留出1/16的空间留作以后的 修改)：

①下一条记录就会写入新的页中，一旦数据按照这种顺序的方式加载，主键页就会近乎于顺序地记录填满，提升了页面的最大填充率，不会有页的浪费

②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快，不会为计算新行的位置而做出额外的消耗

③减少了页分裂和碎片的产生

优点：

1.自增，趋势自增，可作为聚集索引，提升查询效率

2.节省磁盘空间。500W数据，UUID占5.4G,自增ID占2.5G.

3.查询，写入效率高：查询略优。在数据量大时候 高于uuid插入速度

缺点：

1.导入旧数据时，可能会ID重复，导致导入失败。

2.分布式架构，多个Mysql实例可能会导致ID重复。

3.容易被外界攻破，知道业务实际情况。且例如：显示公告内容index?id=3这样就很容易被人篡改为index?id=2.就可以调到第二条的内容。

4对于高并发的负载，innodb在按主键进行插入的时候会造成明显的锁争用，主键的上界会成为争抢的热点，因为所有的插入都发生在这里，并发插入会导致间隙锁竞争。Auto_Increment锁机制会造成自增锁的抢夺,有一定的性能损失

uuid

缺点看上面

雪花id与应用

面试官： 小伙子，你低着头笑什么呐。开始面试了，你知道订单ID是怎么生成的吗？

我： 还能咋生成？用数据库主键自增呗。

面试官： 这样不行啊。数据库主键顺序自增，每天有多少订单量被竞争对手看的一清二楚，商业机密都暴露了。况且单机MySQL只能支持几百量级的并发，我们公司每天千万订单量，hold不住啊。

我： 嗯，那就用用数据库集群，自增ID起始值按机器编号，步长等于机器数量。
比如有两台机器，第一台机器生成的ID是1、3、5、7，第二台机器生成的ID是2、4、6、8。性能不行就加机器，这并发量der一下就上去了。

面试官：小伙子，你想得倒是挺好。你有没有想过实现百万级的并发，大概就需要2000台机器，你这还只是用来生成订单ID，公司再有钱也经不起这么造。

我： 既然MySQL的并发量不行，我们是不是可以提前从MySQL获取一批自增ID，加载到本地内存中，然后从内存中并发取，这并发性能岂不是杠杠滴。

面试官： 你还挺上道，这种叫号段模式。并发量是上去了，但是自增ID还是不能作为订单ID的。

我： 用Java自带UUID怎么样？

importjava.util.UUID;/***@authoryideng*@apiNoteUUID示例*/publicclassUUIDTest{publicstaticvoidmain(String[]args){StringorderId=UUID.randomUUID().toString().replace("-","");System.out.println(orderId);}}输出结果：58e93ecab9c64295b15f7f4661edcbc1

面试官： 也不行。32位字符串会占用更大的空间，无序的字符串作数据库主键，每次插入数据库的时候，MySQL为了维护B+树结构，需要频繁调整节点顺序，影响性能。况且字符串太长，也没有任何业务含义，pass。
小伙子，你可能是没参与过电商系统，我先跟说一下生成订单ID要满足哪些条件：
全局唯一：如果订单ID重复了，肯定要完蛋。 高性能：要做到高并发、低延迟。生成订单ID都成为瓶颈了，那还得了。
高可用：至少要做到4个9，别动不动就宕机了。 易用性：如果为了满足上述要求，搞了几百台服务器，复杂且难以维护，也不行。
数值且有序递增：数值占用的空间更小，有序递增能保证插入MySQL的时候更高性能。
嵌入业务含义：如果订单ID里面能嵌入业务含义，就能通过订单ID知道是哪个业务线生成的，便于排查问题。

我： 我听说圈内有一种流传已久的分布式、高性能、高可用的订单ID生成算法—雪花算法，完全能满足你的上述要求。雪花算法生成ID是Long类型，长度64位。

第 1 位： 符号位，暂时不用。

第 2~42 位： 共41位，时间戳，单位是毫秒，可以支撑大约69年

第 43~52 位： 共10位，机器ID，最多可容纳1024台机器

第 53~64 位： 共12位，序列号，是自增值，表示同一毫秒内产生的ID，单台机器每毫秒最多可生成4096个订单ID

接入非常简单，不需要搭建服务集群，。代码逻辑非常简单，，同一毫秒内，订单ID的序列号自增。同步锁只作用于本机，机器之间互不影响，每毫秒可以生成四百万个订单ID，非常强悍。

生成规则不是固定的，可以根据自身的业务需求调整。如果你不需要那么大的并发量，可以把机器标识位拆出一部分，当作业务标识位，标识是哪个业务线生成的订单ID。

面试官： 小伙子，有点东西，深藏不漏啊。再问个更难的问题，你觉得雪花算法还有改进的空间吗？

你真是打破砂锅问到底，不把我问趴下不结束。幸亏来之前我瞥了一眼一灯的文章。

我： 有的，雪花算法严重依赖系统时钟。如果时钟回拨，就会生成重复ID。

面试官： 有什么解决办法吗？

我： 有问题就会有答案。比如美团的Leaf（美团自研一种分布式ID生成系统），为了解决时钟回拨，引入了zookeeper，原理也很简单，就是比较当前系统时间跟生成节点的时间。

有的对并发要求更高的系统，比如双十一秒杀，每毫秒4百万并发还不能满足要求，就可以使用雪花算法和号段模式相结合，比如百度的UidGenerator、滴滴的TinyId。想想也是，号段模式的预先生成ID肯定是高性能分布式订单ID的最终解决方案。