编程技术网

关注微信公众号,定时推送前沿、专业、深度的编程技术资料。

 找回密码
 立即注册

QQ登录

只需一步,快速开始

极客时间

mysql 事务的隔离级别的实现

你的怀里 mysql 2021-12-22 01:18 188人围观

腾讯云服务器
事务的隔离级别的实现多版本并发控制-MVCC
多版本并发控制(Multi-Version Concurrency Control, MVCC)以乐观锁为理论基础,和基于锁的并发控制最大的区别和优点是:读不加锁,读写不冲突
事务版本号
每次事务开启前都会从数据库获得一个自增长的事务 id,可以从事务 id 判断事务的执行先后顺序。
隐藏字段
InnoDB 存储引擎为每行记录都添加了 3 个隐藏字段:
  • DB_ROW_ID:数据行 id,用于标识一行数据。并不是必要的,如果创建的表中有主键或者非 NULL 唯一键时都不会包含 DB_ROW_ID 列
  • DB_TRX_ID:表示最后一次插入或更新该行的事务 id。此外,delete 操作在内部被视为更新,只不过会在记录头中的 deleted_flag 字段将其标记为已删除
  • DB_ROLL_PTR:当前数据记录的上一个版本的指针。每次对某条数据记录进行改动时,都会把旧版本数据记录按照一定格式写入到回滚日志 (undo log) 中,而 DB_ROLL_PTR 列则保存了该旧版本数据记录在回滚日志中的位置,相当于一个指针。

undo log
MVCC 将每一个更新的数据标记一个版本号,在更新时进行版本号的递增,插入时新建一个版本号,同时旧版本数据存储在 Undo 日志中,该日志通过回滚指针把一个数据行(Record)的所有快照连接起来。
假设在 MySQL 创建一个表 user,包含主键 id 和一个字段 name。我们先插入一个数据行,然后对该数据行执行两次更新操作。
INSERT INTO user(id, name) VALUES(1, "a");UPDATE name SET name="b" WHERE id=1;UPDATE name SET name="c" WHERE id=1;
因为没有使用 START TRANSACTION 将上面的操作当成一个事务来执行,根据 MySQL 的 AUTOCOMMIT 机制,每个操作都会被当成一个事务来执行,所以上面的操作总共涉及到三个事务。

undo log 主要有两个作用:
  • 当事务回滚时用于将数据恢复到修改前的样子,保证事务原子性。
  • 另一个作用是实现 MVCC ,当读取记录时,若该记录被其他事务占用或当前版本对该事务不可见,则可以通过 undo log 读取之前的版本数据,以此实现非锁定读
快照(ReadView)ReadView 结构class ReadView { private:  trx_id_t m_low_limit_id;      /* 大于这个 id 的事务均不可见 */  trx_id_t m_up_limit_id;       /* 小于这个 id 的事务均可见 */  trx_id_t m_creator_trx_id;    /* 创建该 ReadView 的事务 id */  ids_t m_ids;                  /* 创建 ReadView 时的活跃事务列表 */  m_closed;                     /* 标记 ReadView 是否 close */}
ReadView 主要有以下字段:
  • m_creator_trx_id:创建该 ReadView 的事务 id
  • m_ids:ReadView 创建时其他未提交的活跃事务 id 列表。创建 ReadView 时,将当前未提交事务 ID 记录下来,后续即使它们修改了记录行的数据,对于当前事务也是不可见的。注意 m_ids 不包括当前事务自己和已提交的事务(正在内存中)
  • m_low_limit_id:目前出现过的最大的事务 id+1,即下一个将被分配的事务 id。
  • m_up_limit_id :活跃事务列表 m_ids 中最小的事务 id,如果 m_ids 为空,则 m_up_limit_id 等于 m_low_limit_id。

数据可见性算法
InnoDB 存储引擎在开启一个新事务后,执行每个 select 语句前,都会创建一个 ReadView,ReadView 中保存了当前数据库系统中正处于活跃(没有 commit)的事务的 id 号,即系统中当前不应该被该事务看到的其他事务 id 列表 m_ids。当用户在该事务读取某行记录时,InnoDB 会将该行记录的 DB_TRX_ID 与 ReadView 中的一些变量及当前事务 id 进行比较,判断是否满足可见性条件:
  • DB_TRX_ID < m_up_limit_id,表明最新修改该行的事务(DB_TRX_ID)在当前事务创建快照之前就提交了,所以该记录行的值对当前事务是可见的
  • DB_TRX_ID >= m_low_limit_id,那么表明最新修改该行的事务(DB_TRX_ID)在当前事务创建快照之后才修改该行,所以该记录行的值对当前事务不可见
  • m_ids 为空,则表明在当前事务创建快照之前,修改该行的事务就已经提交了,所以该记录行的值对当前事务是可见的
  • m_up_limit_id <= DB_TRX_ID < m_up_limit_id,表明最新修改该行的事务(DB_TRX_ID)在当前事务创建快照的时候可能处于“活动状态”或者“已提交状态”;所以就要对活跃事务列表 m_ids 进行二分查找(m_ids 是有序的):
    • 在 m_ids 中找到 DB_TRX_ID,表明在当前事务创建快照前,该记录行的值被事务 id 为 DB_TRX_ID 的事务修改了,但没有提交;或者在当前事务创建快照后,该记录行的值被事务 id 为 DB_TRX_ID 的事务修改了。这些情况下,这个记录行的值对当前事务都是不可见的
    • 在 m_ids 中找不到 DB_TRX_ID,表明是事务 id 为 DB_TRX_ID 的事务在修改该记录行的值后,在当前事务创建快照前就已经提交了,所以记录行对当前事务可见

在记录行快照不可见的情况下,在该记录行的 DB_ROLL_PTR 指针所指向的 undo log 取出快照记录,用快照记录的 DB_TRX_ID 再重新开始判断,直到找到可见的快照版本或返回空。
事务可见性示意图:

快照读 & 当前读快照读
快照读只是针对于目标数据的版本号小于等于当前事务的版本号,也就是说读数据的时候可能读到旧数据,但是这种快照读不需要加锁。也就是说,使用 MVCC 读取的是快照中的数据,这样可以减少加锁所带来的开销。
select * from table ...;当前读
当前读是读取当前数据的最新版本,但是更新等操作会对数据加锁,所以当前读需要获取记录的行锁,存在锁争的问题。以下第一个语句需要加 S 锁,其它都需要加 X 锁。
select * from table where ? lock in share mode; # 加 S 锁select * from table where ? for update;insert;update;delete;MySQL 中事务隔离级别的实现1. 可串行化(SERIALIZABLE)
读加共享锁(S),写加排他锁(X),读写互斥。
使用的是悲观锁的理论,实现简单,数据更加安全。
2. 提交读(READ COMMITTED) 和可重复读(REPEATABLE READ)
RR 是 InnoDB 存储引擎的默认事务隔离级别。
RC 和 RR 都是基于 MVCC 实现的,但生成快照的时机不同:
  • RC 级别下。每次 select 查询前都会生成一个 ReadView。有可能会出现一个事务中两次读到了不同的结果。
  • RR 级别下。只在事务开始后, 第一次 select 查询前生成一个ReadView。
3. 未提交读(READ UNCOMMITTED)
总是读取最新的数据行,无需使用 MVCC。
InnoDB 行锁算法
Next-Key Locks 是 MySQL 的 InnoDB 存储引擎的一种锁实现。
Record Locks
锁定一个记录上的索引,而不是记录本身
如果表没有设置索引,InnoDB 会自动在主键上创建隐藏的聚簇索引,因此 Record Locks 依然可以使用。
Gap Locks
锁定索引之间的间隙,但是不包含索引本身
例如当一个事务执行以下语句,其它事务就不能在 c 中插入 15。
SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;Next-Key Locks
它是 Record Locks 和 Gap Locks 的结合,不仅锁定一个记录上的索引,也锁定索引之间的间隙,是一个前开后闭区间。例如一个索引包含以下值:10, 11 and 20,那么就需要锁定以下区间:
(-∞, 10](10, 11](11, 20](20, +∞)
如下图所示:

几个问题
问题一:对主键索引或唯一索引会使用间隙锁吗?
不一定。视情况而定:
  • 如果 where 条件全部命中(不会出现幻读),则不会加间隙锁,只会加记录锁
  • 如果 where 条件部分命中 / 全都不命中,则会加间隙锁

delete from tb where id = 9-- Table: tb(name primary key,id unique key) -- key 是唯一索引
根据 id=9 条件定位,此时给 id = 9 的索引加上记录锁,根据 name 值(name是主键)到主索引中检索获得记录,再给该记录加上记录锁。

问题二:间隙锁是否用在非唯一索引的当前读中?
是的。
delete from tb1 where id = 9-- Table: tb1(name primary key,id key)-- key 是非唯一索引
可以看出,在 (6,9]、(9,11] 加了间隙锁。
问题三:间隙锁是否用在不走索引的当前读中?
是的。
delete from tb2 where id = 9-- Table: tb2(name primary key,id)-- 没有为 id 建立索引
此时对所有的间隙都上锁(功能上相当于锁表)。
总结以上三个问题,我们得到如下结论:
  • 主键索引 / 唯一索引:
    如果 where 条件全部命中(不会出现幻读),则不会加间隙锁,只会加记录锁
    如果 where 条件部分命中 / 全都不命中,则会加间隙锁
  • 非唯一索引:
    会加间隙锁
  • 不走索引:
    对所有间隙都加间隙锁,相当于锁表

解决幻读问题
InnoDB 存储引擎在 RR 级别下通过 MVCC + Next-key Lock 来解决幻读问题:
  • 执行 select * from table ...; 会以 MVCC 快照读的方式读取数据。
    在快照读的情况下,RR 隔离级别只会在事务开启后的第一次查询生成 ReadView,使用至事务提交。 在生成 ReadView 之后其它事务所做的更新、插入记录版本对当前事务并不可见,实现了可重复读和防止快照读下的 “幻读”。
  • 执行 select * from table where ? lock in share mode/for update; 、insert、update、delete 会以 MVCC 当前读的方式读取数据。
    在当前读的情况下,读取的都是最新的数据,如果存在其它事务插入新的记录,并且刚好在当前事务查询范围内,就会产生幻读。
    InnoDB 就使用 Next-key Lock 来防止这种情况:当执行当前读时,在锁定读取到的记录时,也会锁定它们的间隙,防止其它事务在查询范围内插入数据。

参考资料
腾讯云服务器 阿里云服务器
关注微信
^