宽屏网站做多少合适,开发app教程,深圳包装设计公司有哪些呢,宁夏网站设计在哪里文章目录 概要一、undo日志1.undo日志的作用2.undo日志的格式3. 事务id#xff08;trx_id#xff09; 二、MVCC1.版本链2.ReadView3.REPEATABLE READ —— 在第一次读取数据时生成一个ReadView4.快照读与当前读 小结 概要
Undo Log#xff1a;数据库事务开始之前#xff0… 文章目录 概要一、undo日志1.undo日志的作用2.undo日志的格式3. 事务idtrx_id 二、MVCC1.版本链2.ReadView3.REPEATABLE READ —— 在第一次读取数据时生成一个ReadView4.快照读与当前读 小结 概要
Undo Log数据库事务开始之前会将要修改的记录存放到 Undo 日志里当事务回滚时或者数据库崩溃时可以利用 Undo 日志撤销未提交事务对数据库产生的影响。
MVCCMulti Version Concurrency Control被称为多版本控制是指在数据库中为了实现高并发的数据访问对数据进行多版本处理并通过版本链保证事务能看到自己应该看到的数据版本。 一、undo日志
Undo意为撤销或取消以撤销操作为目的返回指定某个状态的操作。 Undo Log数据库事务开始之前会将要修改的记录存放到 Undo 日志里当事务回滚时或者数据库崩溃时可以利用 Undo 日志撤销未提交事务对数据库产生的影响。
1.undo日志的作用
undo日志只要有以下两个方面的作用
实现事务的原子性 Undo Log 是为了实现事务的原子性而出现的产物。事务处理过程中如果出现了错误或者用户执行了 ROLLBACK 语句MySQL 可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。实现多版本并发控制MVCC Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前Undo Log保存了未提交之前的版本数据Undo Log 中的数据可作为数据旧版本快照供其他并发事务进行快照读。
2.undo日志的格式
InnoDB行格式
我们平时是以记录为单位来向表中插入数据的这些记录在磁盘上的存放方式也被称为行格式或者记录格式。
InnoDB一共有四种行格式Compact、Redundant、Dynamic和Compressed行格式行格式之间存在差异但总体可以抽象成以下部分
聚簇索引的记录除了会保存完整的用户数据以外而且还会自动添加名为trx_id、roll_pointer的隐藏列如果用户没有在表中定义主键以及UNIQUE键还会自动添加一个名为row_id的隐藏列。
trx_id某个对这个聚簇索引记录做改动的语句所在的事务对应的事务id此处的改动可以是INSERT、DELETE、UPDATE操作 roll_pointer每次对某条聚簇索引记录进行改动时都会把旧的版本写入到undo日志中然后这个隐藏列就相当于一个指针可以通过它来找到该记录修改前的信息
undo日志格式
为了实现事务的原子性InnoDB存储引擎在实际进行增、删、改一条记录时都需要先把对应的undo日志记下来。一般每对一条记录做一次改动就对应着一条undo日志。不同的操作insert,delete,update对应的undo日志有所差异他们对应的undo日志格式展示如下。这里不会展开对每种日志字段进行说明主要还是总结他们的差异和作用以及跟行数据之间是如何通过roll_pointer属性进行联系。
insert操作的undo日志 这里需要注意的是insert操作对应的undo日志没有roll_pointer属性的因为该记录并没有更早的版本。
插入一条数据时行记录跟undo日志的关系如下
delete操作的undo日志 重点关注
delete操作的undo日志有roll_pointer属性delete操作是分为两个阶段来操作的delete mark 阶段和 purge阶段在delete mark阶段并不会真正地将数据从页面中清除而是设置头信息为delete标识在这个阶段同时将数据加入到版本链中。
update操作的undo日志 更新时有以下几种情况
3. 事务idtrx_id
一个事务可以是一个只读事务或者是一个读写事务
可以通过START TRANSACTION READ ONLY语句开启一个只读事务。 在只读事务中不可以对普通的表其他事务也能访问到的表进行增、删、改操作但可以对临时表做增、删、改操作。可以通过START TRANSACTION READ WRITE语句开启一个读写事务或者使BEGIN、START TRANSACTION语句开启的事务默认也算是读写事务。 在读写事务中可以对表执行增删改查操作。如果某个事务执行过程中对某个表执行了增、删、改操作那么InnoDB存储引擎就会给它分配一个独一无二的事务id
常见的场景
上图操作中虽然已经开启了一个事务并且也对某张表进行了查询操作但是因为没有对表进行增删改操作这个时候InnoDB引擎是不会分配事务id的。
二、MVCC
MVCCMulti Version Concurrency Control被称为多版本控制是指在数据库中为了实现高并发的数据访问对数据进行多版本处理并通过版本链保证事务能看到自己应该看到的数据版本。 多版本控制很巧妙地将稀缺资源的独占互斥转换为并发大大提高了数据库的吞吐量及读写性能。 如何生成的多版本每次事务修改操作之前都会在Undo日志中记录修改之前的数据状态和事务号该备份记录可以用于其他事务的读取也可以进行必要时的数据回滚。
MVCC最大的好处是读不加锁读写不冲突。在读多写少的系统应用中读写不冲突是非常重要的极大的提升系统的并发性能这也是为什么现阶段几乎所有的关系型数据库都支持 MVCC 的原因不过目前MVCC只在Read Commited 和 Repeatable Read 两种隔离级别下工作。
1.版本链
创建一张表,并向数据表中添加一条记录
CREATE TABLE user_mvcc (id bigint NOT NULL AUTO_INCREMENT,name varchar(20) NOT NULL,PRIMARY KEY (id)
) ENGINEInnoDB;insert into user_mvcc (name) VALUES(Tom);
# 查询
mysql select * from user_mvcc where id 6;
--------------
| id | name |
--------------
| 6 | Tom |
--------------
1 row in set (0.11 sec)
之后两个事务id分别为100、200的事务对id6这条记录进行UPDATE操作操作流程如下
每次对记录进行改动都会记录一条undo日志每条undo日志也都有一个roll_pointer属性INSERT操作对应的undo日志没有该属性因为该记录并没有更早的版本可以将这些undo日志都连起来串成一个链表:
对该记录每次更新后都会将旧值放到一条undo日志中就算是该记录的一个旧版本随着更新次数的增多所有的版本都会被roll_pointer属性连接成一个链表我们把这个链表称之为版本链版本链的头节点就是当前记录最新的值。另外每个版本中还包含生成该版本时对应的事务id。
2.ReadView
使用READ COMMITTED或者REPEATABLE READ隔离级别在当前事务中必须保证以下两点
能读到已经提交了的事务修改过的记录不能读取到另一个事务已经修改的但是尚未提交的记录。这个时候就要继续往上找该条记录的上一个版本在依照一定的规则判断该版本的记录是否可见。这个规则下面进行介绍。
所以核心问题就是需要判断一下版本链中的哪个版本是当前事务可见的。为此设计InnoDB的大佬提出了一个ReadView的概念这个ReadView中主要包含4个比较重要的内容 m_ids表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。 min_trx_id表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id也就是m_ids中的最小值。 max_trx_id表示生成ReadView时系统中应该分配给下一个事务的id值 注意max_trx_id并不是m_ids中的最大值事务id是递增分配的。比方说现在有id为123这三个事务之后id为3的事务提交了。那么一个新的读事务在生成ReadView时m_ids就包括1和2min_trx_id的值就是1max_trx_id的值就是4 creator_trx_id表示生成该ReadView的事务的事务id 只有在对表中的记录做改动时执行INSERT、DELETE、UPDATE这些语句时才会为事务分配事务id否则在一个只读事务中的事务id值都默认为0。
数据版本的可见性规则就是基于数据的 row trx_id 和这个一致性视图的对比结果得到的。 有了这个ReadView这样在访问某条记录时只需要按照下面的步骤判断记录的某个版本是否可见
如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同意味着当前事务在访问它自己修改过的记录所以该版本可以被当前事务访问。如果被访问版本的trx_id属性值小于ReadView中的min_trx_id值表明生成该版本的事务在当前事务生成ReadView前已经提交所以该版本可以被当前事务访问。如果被访问版本的trx_id属性值大于ReadView中的max_trx_id值表明生成该版本的事务在当前事务生成ReadView后才开启所以该版本不可以被当前事务访问。如果被访问版本的trx_id属性值在ReadView的min_trx_id和max_trx_id之间那就需要判断一下trx_id属性值是不是在m_ids列表中如果在说明创建ReadView时生成该版本的事务还是活跃的该版本不可以被访问如果不在说明创建ReadView时生成该版本的事务已经被提交该版本可以被访问。
如果某个版本的数据对当前事务不可见的话那就顺着版本链找到下一个版本的数据继续按照上面的步骤判断可见性依此类推直到版本链中的最后一个版本。如果最后一个版本也不可见的话那么就意味着该条记录对该事务完全不可见查询结果就不包含该记录。
下面以REPEATABLE READ隔离级别下的MVCC演示说明。
3.REPEATABLE READ —— 在第一次读取数据时生成一个ReadView
还是以user_mvcc中id为6的数据举例
mysql select * from user_mvcc where id 6;
--------------
| id | name |
--------------
| 6 | lisi |
--------------
1 row in set (0.08 sec)有3个事务的执行顺序如下
下面通过以上的规则说明为什么trx300两次查询的结果是lisi.
在trx100执行时间点5完成后user_mvcc表中id6的记录得到的版本链如下 在时刻6事务trx200执行更新其他表的操作主要是为了分配事务id
时刻7查询1的分析如下
在执行SELECT语句时会先生成一个ReadViewReadView的m_ids列表的内容就是[100, 200]min_trx_id为100max_trx_id为201creator_trx_id为0。然后从版本链中挑选可见的记录从图中可以看出最新版本的列name的内容是’jack’该版本的trx_id值为100在m_ids列表内所以不符合可见性要求根据roll_pointer跳到下一个版本。下一个版本的列name的内容是’Ally’该版本的trx_id值也为100也在m_ids列表内所以也不符合要求继续跳到下一个版本。下一个版本的列name的内容是’lisi’该版本的trx_id值为80小于ReadView中的min_trx_id值100所以这个版本是符合要求的最后返回给用户的版本就是这条列name为’lisi’的记录。
之后trx100事务提交trx200执行更新user_mvcc表的id6的记录此时该条记录的版本链如下 时刻10查询2的分析如下
因为当前事务的隔离级别为REPEATABLE READ而之前在执行第一次查询时已经生成过ReadView了所以此时直接复用之前的ReadView之前的ReadView的m_ids列表的内容就是[100, 200]min_trx_id为100max_trx_id为201creator_trx_id为0。然后从版本链中挑选可见的记录从图中可以看出最新版本的列name的内容是’leilei’该版本的trx_id值为200在m_ids列表内所以不符合可见性要求根据roll_pointer跳到下一个版本。下一个版本的列name的内容是’jack’该版本的trx_id值为100也在m_ids列表内所以也不符合要求继续跳到下一个版本。下一个版本的列name的内容是’Ally’该版本的trx_id值为100也在m_ids列表内不符合继续跳到下一个版本。下一个版本的列name的内容是’lisi’该版本的trx_id值为80小于ReadView中的min_trx_id值100所以这个版本是符合要求。
也就是说两次SELECT查询得到的结果是相同都是’lisi’这就是可重复读的含义。
READ COMMITTD、REPEATABLE READ这两个隔离级别的一个很大不同就是生成ReadView的时机不同READ COMMITTD在每一次进行普通SELECT操作前都会生成一个ReadView而REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView之后的查询操作都重复使用这个ReadView。
4.快照读与当前读
有以下数据
mysql select * from t where id 1;
-------
| id | c |
-------
| 1 | 1 |
-------
1 row in set (0.09 sec)
现在有以下操作场景 那么此时图中的SELECT1,SELECT2,SELECT3查询得到的c的值分别是多少
根据前面的分析很容易得到SELECT1,SELECT2得到c的值是1而在SELECT3中按照前面的分析应该得到c的值为2但实际查询得到的结果是c 3,那为什么会出现这种结果呢
在 MVCC 并发控制中读操作可以分为两类: 快照读Snapshot Read与当前读 Current Read。
快照读读取的是记录的快照版本有可能是历史版本不用加锁。我们平时的select操作就是快照读。当前读读取的是记录的最新版本并且当前读返回的记录都会加锁保证其他事务不会再并发修改这条记录。 开启当前读的方式有select… for update 或lock in share mode 平时的insert/delete/update操作也是用的当前读的方式
所以图上的UPDATE2场景就是用到了当前读更新数据都是先读后写;
在UPDATE2更新之前事务trx300执行了更新此次该条数据的版本链中最新的数据为(1,2)当UPDATE2再进行更新时因为是当前读所以会拿到最新的值2进行操作当UPDATE2执行完后版本链中该条数据的c值就变成了3所以在SELECT3中查看到的c的值为3.
小结
所谓的MVCCMulti-Version Concurrency Control 多版本并发控制指的就是在使用READ COMMITTD、REPEATABLE READ这两种隔离级别的事务在执行普通的SEELCT操作时访问记录的版本链的过程这样子可以使不同事务的读-写、写-读操作并发执行从而提升系统性能。MVCC的实现是通过undo日志来完成的。
InnoDB 的行数据有多个版本每个数据版本有自己的 row trx_id每个事务或者语句有自己的一致性视图。普通查询语句是一致性读(快照读)一致性读会根据 row trx_id 和一致性视图确定数据版本的可见性。
REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView之后的查询操作都重复使用这个ReadViewREAD COMMITTD:每一次进行普通SELECT操作前都会生成一个ReadView
更新数据操作都是先读后写的读的都是版本链中最新的值称为“当前读”current read
