每日一面 - mysql 的自增 id 的实现逻辑是什么样子的?

2021-01-05  本文已影响0人  干货满满张哈希

本问题参考自: https://www.zhihu.com/question/437916819/answer/1661679374, 解答为个人原创

Key TakeAways

为何主键要 Auto Increment 而不是 UUID

MySQL InnoDB 引擎默认主键索引是 B+ 树索引,也是聚集索引,为何叫聚集索引呢?

以 InnoDB 作为存储引擎的表,表中的数据都会有一个主键,即使你不创建主键,系统也会帮你创建一个隐式的主键。这是因为 InnoDB 是把数据存放在 B+ 树中的,而 B+ 树的键值就是主键,在 B+ 树的叶子节点中,存储了表中所有的数据。这种以主键作为 B+ 树索引的键值而构建的 B+ 树索引,我们称之为聚集索引。

存储中,聚集索引的数据,会根据索引的值,对应的数据也会聚集存储在一起:

image

MySQL 读取磁盘上的数据是一页一页读取的,如果某条我们要处理的数据在某一页中,但是这一页其他数据我们都不关心,这样的请求多了,性能会急剧下降,类似于 CPU 的 false sharing:

[图片上传失败...(image-526588-1609819492984)]

按照 B+ 树的原理,AutoIncrement 的 ID 能保证最新的数据在一页中被读取,而且减少了 B+ 树分裂翻转。 UUID 由于无序,插入时,B+ 树会不断翻转,并且最新的数据可能不在同一页。很可能会出现,最新一条数据,和好几年前的数据在同一页。

在大部分 OLTP 类业务中,例如购物和支付交易的订单,节日促销的抽奖活动这类业务都有这样的使用场景,访问频率在最近一天,一周,或者几个月内比较活跃,而超过一段时间内的数据很少访问。如果是这类业务推荐使用自增主键,将业务主键(UUID)作为二级的唯一索引使用。
如果考虑分布式性能以及避免 AutoIncrement 带来的锁性能问题,可以考虑使用 ID 生成器生成全局趋势增长的主键,例如 Twitter 的 Snowflake 算法生成的前面是时间戳的主键id,或者是 类似于这种 "时间+业务+自增"(例如 20210105105811233ORD0000001) 字符串,作为主键id,这样其实也能近似保证热数据聚集存储在一起,也就是 MySQL 一页一页读取能命中更多要读取处理的数据

AutoIncrement 原理

我们这里只关心 InnoDB 引擎的。

AutoIncrement 最大值

AutoIncrement 最大值,和列类型相关。最大可以设置列类型为 UNSIGNED BIGINT,这样最大值就是 18446744073709551615。 超过这个值继续生成则还是 18446744073709551615。不会再增加。

AutoIncrement 锁模式

获取 AutoIncrement 最新值,需要涉及到锁。目前有三种锁模式,对应 innodb_autoinc_lock_mode 的值, 0 ,1,2. MySQL 8.0 之后,默认为 2, 在这之前,默认为 1

AutoIncrement 存储

AutoIncrement 计数器在 MySQL 8.0 之前,存储在内存中,每次启动时通过以下语句初始化:

SELECT MAX(ai_col) FROM table_name FOR UPDATE;

在 MySQL 8.0 之后,持久化存储到磁盘。通过每次更新写入 Redo Log,并在检查点刷入 innodb 引擎表中记录下来。

所以,在MySQL 8.0 之前,如果 rollback 导致某些值没有使用,重启后,这些值还是会使用。但是在 MySQL 8.0 之后就不会了

上一篇 下一篇

猜你喜欢

热点阅读