每当我们要对一条记录做改动时(这里的改动可以指 INSERT 、 DELETE 、 UPDATE ),都需要留一手 -> 把回滚时所需的东西都给记下来
你插入一条记录时,至少要把这条记录的主键值记下来,之后回滚的时候只需要把这个主键值对应的记录删掉就好了。
你删除了一条记录,至少要把这条记录中的内容都记下来,这样之后回滚时再把由这些内容组成的记录插入到表中就好了。
你修改了一条记录,至少要把修改这条记录前的旧值都记录下来,这样之后回滚时再把这条记录更新为旧值 就好了。
我们说过 事务 需要保证 原子性 ,也就是事务中的操作要么全部完成,要么什么也不做。但是偏偏有时候事务执 行到一半会出现一些情况,比如:
- 情况一:事务执行过程中可能遇到各种错误,比如服务器本身的错误,操作系统错误,甚至是突然断电导致 的错误。
- 情况二:程序员可以在事务执行过程中手动输入 ROLLBACK 语句结束当前的事务的执行
这两种情况都会导致事务执行到一半就结束,但是事务执行过程中可能已经修改了很多东西,为了保证事务的原 子性,我们需要把东西改回原先的样子,这个过程就称之为 回滚 (英文名: rollback ),这样就可以造成一个 假象:这个事务看起来什么都没做,所以符合 原子性 要求。
undo log是一种用于撤销回退的日志,在数据库事务开始之前,MySQL会先记录更新前的数据到 undo log日志文件里面,当事务回滚时或者数据库崩溃时,可以利用 undo log来进行回退。
注意: undo log 也会产生 redo log ,因为 undo log 也需要持久性保护。
在更新数据之前,MySQL会提前生成undo log日志,并且在事务提交之前不会立即删除undo log,以确保事务执行失败时可以进行回滚操作。而undo log日志的删除是通过后台的purge线程进行回收处理的。
事务A执行update更新操作时,会按照以下步骤进行:
在事务A执行的过程中,如果事务B对数据进行了查询,根据MySQL的MVCC机制,事务B会读取到数据的快照版本,即事务A更新之前的版本。这样可以保证事务B读取到的是一致的数据视图,即使事务A正在更新数据。
为了保证事务并发操作时,在写各自的undo log时不产生冲突,InnoDB采用回滚段
的方式来维护undo log的并发写入和持久化。
回滚段概述
并发事务执行限制
START TRANSACTION; -- 开启事务A
-- 执行更新操作
UPDATE table_name SET column_name = value WHERE condition;
COMMIT; -- 提交事务A
-- 开启另一个事务B
START TRANSACTION;
-- 执行查询操作
SELECT * FROM table_name WHERE condition;
COMMIT; -- 提交事务B
事务执行过程中在对某个表执行增、删、改操作时,InnoDB就会给这个事务分配一个唯一的事务ID。
可以通过 information_schema.INNODB_TRX
来查询当前系统中运行的事务信息.
START TRANSACTION;
select * from test1.a1;
commit;
--trx_id 就是事务ID,InnoDB 在内存维护了一个全局变量来表示事务ID,每当要分配一个事务ID时,就获取这个变量值,然后把这个变量自增1
select
trx_id ,
trx_state ,
trx_started,
trx_isolation_level
from information_schema.INNODB_TRX;
InnoDB引擎管理的数据表中每行行记录,都存在着三个隐藏列
DB_ROW_ID
: 如果没有为表显式的定义主键,并且表中也没有定义唯一索引,那么InnoDB会自动为表添加一个row_id的隐藏列作为主键。DB_TRX_ID
: 事务中对某条记录做增删改时,就会将这个事务的事务ID写入到trx_id中.DB_ROLL_PTR
: 回滚指针,指向undo log的指针插入一条数据对应的undo操作其实就是根据主键删除这条数据就行了。
所以 insert 对应的 undo log 主要是把这条记录的主键记录上
TRX_UNDO_INSERT_REC
。通过一个事物操作,我们一起来看一下回滚链的形成
MySQL 与undo相关的参数设置:
mysql> show variables like '%undo%';
+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| innodb_max_undo_log_size | 1073741824 |
| innodb_undo_directory | ./ |
| innodb_undo_log_truncate | OFF |
| innodb_undo_logs | 128 |
| innodb_undo_tablespaces | 0 |
+--------------------------+------------+
mysql> show global variables like '%truncate%';
+--------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------+-------+
| innodb_purge_rseg_truncate_frequency | 128 |
| innodb_undo_log_truncate | OFF |
+--------------------------------------+-------+
innodb_undo_log_truncate=ON
,才会触发truncate回收(收缩)动作,被truncate后的表空间文件大小缩小到undolog表空间数据文件默认的1OMB大小。否则即便是到达最大值之后,也不会自动回收undolog的表空间。innodb_undo_directory
目录存放,可以制定到高速磁盘上,加快undo log 的读写性能。ON
,并且配置了2个或2个以上的undolog表空间数据文件,当某一个日志文件大小超过设置的最大值之后,就会自动的收缩表空间数据文件。在回收表空间数据文件的时候,被回收的表空间数据文件会临时下线,为了保证undolog一直有地方可以写,此时要保证至少还有1个undolog日志文件是在线的。这就是要求
innodb_undo_tablespaces>=2
的根本原因