Mysql 自增id、uuid与雪花id

概念介绍

三种主键

自增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怎么样?

import java.util.UUID;
/**
 * @author yideng
 * @apiNote UUID示例
 */
public class UUIDTest {
    public static void main(String[] args) {
        String orderId = 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的最终解决方案。

参考资料:https://blog.csdn.net/murongguofu/article/details/125220736 他的博客似乎都还不错

总结

1、旧系统或者单部署系统,一般都采用自增主键,主要是便捷性考虑。优缺点如下:

优点:自增长字段往往用integer bigint类型,最多占8个字节。索引与外键 所占用的空间连带减少,增删改查 效率高。业务变化,不影响,不需要更新主键。
缺点:无法转移数据库,比如把表中的一批数据 转移 或 附带到 另一个表中,那么由于是自增长字段,那么会导致无法转移,因为另外一个表可能已经存在部分数据,会造成主键冲突。自增长字段的缺陷。业务数据的完整性,无法保证。

2、对于高并发业务型数据表,尤其是分布式部署架构,一般建议尽量使用业务主键,主要是考虑到查询效率、安全性以及分表分库等的情况,优缺点如下:

优点:可以转移数据库,最大化节省了空间,因为并没有多增加一个非业务字段做主键。可以保证业务逻辑的完整性。避免产生垃圾数据,银行就是用业务字段做主键的,虽然效率低,但是安全。
缺点:如果业务发生改变,有可能需要修改主键,举例:国家A表用身份证号做主键,然后其他很多表中的身份证号这列都是来自身份证表A中的主键(即外键),那么如果身份证号升级,比如从1代升级到2代,那么连带的表的外键 的索引 通通都得发生变化,效率极低 因为会连带更新一串用到这个外键的表,可见用业务字段做主键的话,要保证主键不经常变化。

  • 27
    点赞
  • 94
    收藏
    觉得还不错? 一键收藏
  • 3
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值