事务

事务：保证一系列操作是原子操作，即保证同时成功，同时失败。

注意，要想使用事务，必须使用支持事务的存储引擎，比如innodb

使用事务

1. 显示开启事务

   -- 使用事务需要使用innodb存储引擎
   -- 开启事务
   start transaction;
   -- 当事务中的某一操作发生异常，事务会被rollback
   -- 提交事务, 事务完成
   commit transaction;

2. 在InnoDB引擎中，如果没有显示的开启事务

   • 如果你设置AUTOCOMMIT = 1，表示开启自动提交，每执行一个SQL都会开启一个事务，并自动提交

   • 如果你设置AUTOCOMMIT = 0，表示关闭自动提交，第一次执行SQL将会开启一个事务，以后的每条SQL都会加入到这个事务中，直到你手动执行COMMIT提交事务。

事务的状态

image-20220308221452397

事务的四个属性

1. 原子性 ATOMICITY，一个事务中的所有操作，是一个原子操作，要么全部成功，要么全部失败。

2. 一致性 CONSISTENCY，就是在事务执行前后，对于事务本身的用意而言，数据库中的数据是保持一致的，比如A向B转账500，但是B收到了300，就违反了一致性。

3. 隔离性 ISOLATION，事务的隔离性是指事务和事务之间的数据可见性。 只要这个事务操作没有完成，其他人是看不到任何数据改变的。

4. 持久性 DURABILITY，事务完成后，所有数据都会持久化到数据库中，无法撤销。

原子性、一致性、持久性由事务的redo log、undo log实现，而隔离性由锁来实现

事务的并发问题

时间点	事务A	事务B
1	开启事务A
2		开启事务B
3	查询余额 100
4		余额增加到150
5	查询余额150 （此处就发生了脏读）
6	余额增加到200 （此处发生了脏写）
7		事务回滚
8	事务提交（脏数据被写入）

脏写

时间点	事务A	事务B
1	开启事务A
2		开启事务B
3	查询余额 100
4		余额增加到150
5	查询余额150 （此处就发生了脏读）
6		事务回滚

脏读

读到了事务还未提交的数据，称为脏读。脏读读取出的数据都是错误的数据。

时间点	事务A	事务B
1	开启事务A
2		开启事务B
3	查询余额 100
4		余额增加到150
5	查询余额150 （此处就发生了脏读）
6		事务回滚

不可重复度

指在一个事务内多次读同一数据。这个数据正在被其他事务操作，导致多次读取的结果不同。对于不可重复度来说，读取的数据都是正确的数据。

时间点	事务A	事务B
1	开启事务A
2		开启事务B
3	查询余额100
4		余额增加到150
5	查询余额100
6		提交事务
7	查询余额150（发生了不可重复度）

幻读

与不可重复度类似。当一个事务读取指定范围的数据时，另一个事务插入了一些数据。导致事务在后面的查询中，出现了一些原本不存在的数据记录，就好像发生了幻觉一样，所以成为幻读。和不可重复度相同，幻读到的数据实际上时正确的数据。

时间点	事务A	事务B
1	开启事务A
2		开启事务B
3	查询id<3的记录，共3条
4		插入id=2的一条记录
5		提交事务
6	查询id<3的记录，共4条（发生了幻读）

不可重复度 和 幻读的区别

不可重复度的重点是修改，幻读的重点在于新增或者删除。

为什么区分为两个概念？

不可重复读： 如果是修改，则增加行锁就可以解决，因为只设计到一条数据
幻读：      而新增、删除，涉及到多条数据，需要使用表锁

事务的隔离级别

为了解决事务的并发问题，提供了事务的隔离机制，共有四种事务的隔离级别，最高级别可以防止事务的并发问题：

隔离级别	脏写问题	脏读问题	不可重复读问题	幻读问题
READ-UNCOMMITTED	无	有	有	有
READ-COMMITTED	无	无	有	有
REPEATABLE-READ	无	无	无	有
SERIALIZABLE	无	无	无	无

MySQL中，所有的隔离级别都可以解决脏写问题

1. READ-UNCOMMITTED：当事务1对目标值修改时，事务2如果也要对目标值修改，为保证不引发脏写，事务2将会阻塞等待事务1的提交。（通过给指定的行增加一个读写锁）

2. READ-COMMITTED：当事务1对目标值修改时，事务2查询目标的值，为保证不引发脏读，事务2将会阻塞等待事务1的提交。

3. REPEATABLE-READ：事务1不断对目标修改并，事务2不断查询目标，可以发现每次目标的值都是相同的，是刚刚开启事务的值。

4. SERIALIZABLE：

image-20220308203418430

查询/设置隔离级别

查询隔离级别：

-- 查看隔离级别，MySQL 5.7.20的版本之前：
mysql> SHOW VARIABLES LIKE 'tx_isolation';

-- MySQL 5.7.20版本之后，引入transaction_isolation来替换tx_isolation
mysql> SHOW VARIABLES LIKE 'transaction_isolation';

-- 下面这个方法，无论什么版本都可以使用
mysql> SELECT @@transaction_isolation;

默认的隔离级别为：REPEATABLE-READ，Oracle 默认的隔离级别为READ-COMMITTED。

设置当前会话的事务的隔离级别：

set session transaction isolation level read uncommitted;
set session transaction isolation level read committed;
set session transaction isolation level repeatable read;
set session transaction isolation level serializable;

MySQL的事务日志

事务的原子性、一致性、持久性都由事务的redo以及undo日志来保证。

1. redo log 称为重做日志，提供再写入操作，恢复提交事务修改的页操作，用来保证事务的持久性。

   存储引擎层生成的日志，记录的是物理级别上的页(page)的修改操作，比如在页号x-偏移量y的行上写入了xxx的数据，主要是为了保证数据的可靠性。

2. undo log称为回滚日志，回滚行记录到某个版本，用来保证事务的原子性、一致性。

   存储引擎层生成的日志，记录的是逻辑操作的逆操作，比如inser xxx、update xxxx 等SQL语句，他会记录一个与之相反的SQL操作，其中insert xxx就会对应一个delete xxx操作，update a = 1 会记录对应一个update a = 原值的操作。

redo 和 undo主要是存储引擎提供的用于保证事务特性的功能，注意只适用于事务，非事务的情况不适用。

Buffer Pool 缓冲池

应用系统分层架构，为了加速数据访问，会把最常访问的数据，放在缓存(cache)里，避免每次都去访问数据库。操作系统，会有缓冲池(buffer pool)机制，避免每次访问磁盘，以加速数据的访问。MySQL作为一个存储系统，同样具有缓冲池(buffer pool)机制，以避免每次查询数据都进行磁盘IO。

image-20220314170520195

redo日志（持久性）

因为Buffer Pool机制是采用定期刷入磁盘的，所有在缓存池中还未刷入磁盘的数据会有可能因为MySQL的故障导致数据的丢失，从而无法保证其持久性。故引入redo log解决持久性问题。

image-20220309091620411

整个过程：

1. 先将原始数据（按照页的单位）从磁盘中读入内存中来，当事务发生update更新操作时，修改数据的内存拷贝

2. 然后生成一条重做日志并写入redo log buffer，记录的是数据被修改后的值

3. 当事务commit时，将redo log buffer中的内容刷新到redo log file，对 redo log file采用追加写的方式

4. 定期将内存中修改的数据刷新到磁盘中

特点：

1. redo日志是顺序写入磁盘的，而不是随机写入，所以他的写入速度、读取速度都很快。（顺序写入降低了磁头的反复移动而导致的时间损失）

2. 事务执行的过程中，redo log不断记录到redo log buffer中

3. redo log记录的是物理操作，所以日志文件占用的空间特别小

4. 使用redo log buffer而不是每有一个操作就写入磁盘，是因为需要buffer缓冲池减少写入磁盘的IO次数，降低IO成本

5. 如果在事务commit之后，mysql发生异常退出，步骤4可能会被中断，但是redo log file中记录了所有重做日志，mysql重启后可以很容易的进行恢复。故redo日志解决了事务的持久性。

物理介质不同时，总会采用缓冲池的方式来解决介质之间的速度问题。避免了频繁的数据交互与等待。

组成：

• 重做日志的缓冲 (redo log buffer) ，保存在内存中，是易失的。 （下图是一个连续存储结构）

  

  image-20220309092623387

  redo log buffer的默认大小为16M，最大值为4096M，最小值为1M。可以使用如下变量设置、查询该参数：

  mysql> show variables like '%innodb_log_buffer_size%';
  +------------------------+----------+
  | Variable_name          | Value    |
  +------------------------+----------+
  | innodb_log_buffer_size | 16777216 |
  +------------------------+----------+
  1 row in set (0.04 sec)

  redo log buffer 里面由多个连续的log block块组成（每个512bytes），每个块又由三个部分组成。

• 重做日志文件 (redo log file) ，保存在硬盘中，是持久的。

  它存储在mysql的数据目录下/var/lib/mysql

  -rw-r----- 1 mysql mysql 50331648 Feb 28 02:31 ib_logfile0
  -rw-r----- 1 mysql mysql 50331648 Feb 28 02:31 ib_logfile1

redo log buffer 刷盘到 redo log file 的刷盘策略（步骤3）：

1. innodb_flush_log_at_trx_commit 为 0：表示每次事务提交时不进行刷盘操作。（系统默认master thread每隔1s进行一次重做日志的同步）

   

   image-20220309094757783
2. innodb_flush_log_at_trx_commit 为 1：表示每次事务提交时都将进行同步，刷盘操作（ 默认值 ）

   

   image-20220309094731910
3. innodb_flush_log_at_trx_commit 为 2：表示每次事务提交时都只把 redo log buffer 内容写入 page cache，不进行同步。由os自己决定什么时候同步到磁盘文件

   

   image-20220309094810575

undo日志（原子性）

undo log名为回滚日志，是实现原子性的关键。

1. 当事务发生更新操作之前，会先写入一条undo log，用于记录更新之前的版本。注意，他是一个逻辑日志，记录的是数据的变化过程

2. 当对一条数据在同一个事务中发生多次更新操作时，会产生一个undo log 链表

3. 如果事务发生了回滚，会依次执行链表中的所有日志，最终回滚到数据的初始状态

4. 如果事务发生了提交，并不会立即删除undo log的页。这是因为其他事务有可能还需要通过undo log来得到行记录之前的版本。所以事务提交时将会把undo log放入到一个链表中，是否可以最终删除undo log以及它所在的页由purge线程来判断。

当事务回滚时能够撤销所有已经成功执行的sql语句，他需要记录你要回滚的相应日志信息。例如：

1. 当你delete一条数据的时候，就需要记录这条数据的信息，回滚的时候，insert这条旧数据

2. 当你update一条数据的时候，就需要记录之前的旧值，回滚的时候，根据旧值执行update操作

3. 当年insert一条数据的时候，就需要这条记录的主键，回滚的时候，根据主键执行delete操

undo log记录了这些回滚需要的信息，当事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。

undo log 也会产生 redo log，用来保证undo log的持久性。

主要作用

1. 回滚数据：所谓的回滚数据并不是恢复到之前没有发生的状态，而是执行相反逻辑的SQL对数据重新修改。

2. MVCC机制实现：InnoDB存储引擎的MVCC借助了undo来完成。当用户读取一条记录时，若该记录已经被其他事务占用，当前事务可以通过undo读取之前的版本信息，以此实现非锁定读取。

存储结构

InnoDB对undo log的管理采用回滚段（rollback segment）管理。每个回滚段记录了 1024 个undo log segment，而在每个undo log segment段中进行undo页的申请。

1. 在InnoDB1.1版本之前，只有一个回滚段

2. 在InnoDB1.1版本以及之后，支持最大128个回滚段

回滚段的存储路径以及方式：

1. 在InnoDB1.2之前，回滚段存储在ibdata共享表空间中

2. 在InnoDB1.2及其之后，回滚段可以通过如下几个设置更改他的文件存储方式：

   1. innodb_undo_directory：设置回滚段文件的存储路径，默认为./，也就是InnoDB存储引擎的目录。

   2. innodb_undo_logs：设置回滚段的个数，默认值是128个

   3. innodb_undo_tablespaces：设置构成回滚段的文件数量，让回滚段平均分配于多个文件。他会在innodb_undo_directory看到后缀为undo的多个文件。

整体结构与流程

下面是行格式，一个行格式中除了存储了每列的数据外，还提供了三个隐藏列：

image-20220317170938119

1. DB_ROW_ID，目标行如果没有主键，会自动生成一个DB_ROW_ID隐藏列作为主键

2. DB_TRX_ID，每个事务都会分配一个事务ID，当对某条记录发生变更时，就会将这个事务的事务ID写入到这个隐藏字段中

3. DB_ROLL_PTR，回滚指针，它指向undo log链表

当事务发生Insert操作时，比如：

begin;
INSERT INTO user (name) VALUES ("tom");

image-20220317170053006

将会创建一条undo log，其格式为Insert Undo Log，其中undo no也就是日志序列号为0。

当事务发生Update操作时，将会再次产生一个Undo Log，其类型为 Update Log：

UPDATE user SET name='Sun' WHERE id=1;

image-20220317170126656

如果修改的值是主键，那么将会将原有的记录标记删除，然后创建一条新的记录：

UPDATE user SET id=2 WHERE id=1;

image-20220317170515133

image-20220314172803675

怎么保证事务的一致性？

从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性。也就是说ACID四大特性之中，C(一致性)是目的，A(原子性)、I(隔离性)、D(持久性)是手段，是为了保证一致性，数据库提供的手段。数据库必须要实现AID三大特性，才有可能实现一致性。例如，原子性无法保证，显然一致性也无法保证。

但是，如果你在事务里故意写出违反约束的代码，一致性还是无法保证的。例如，你在转账的例子中，你的代码里故意不给B账户加钱，那一致性还是无法保证。因此，还必须从应用层角度考虑。

从应用层面，通过代码判断数据库数据是否有效，然后决定回滚还是提交数据！

MVCC

MVCC （Multiversion Concurrency Control），多版本并发控制。他是基于快照隔离机制(Snapshot Isolations)进行多版本并发控制，是一种以乐观锁为理论基础的，用来解决读-写冲突的无锁并发控制。这项技术使得在InnoDB的事务隔离级别下执行 一致性读操作有了保证。换言之，就是为了查询一些正在被另一个事务更新的行，并且可以看到它们被更新之前的值，这样在做查询的时候就不用等待另一个事务释放锁。

快照读和当前读

快照读：

1. 快照读又叫一致性读，读取的是快照数据。

2. 快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读

3. 基于前提，不加锁的非阻塞读都是快照读，比如：

   SELECT * FROM player WHERE ...

4. 快照读是为了提高并发性能而产生的基于MVCC原理的读取方式

5. 因为基于多版本，那么快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本

当前读：

1. 当前读读取的是记录的最新版本（最新数据，而不是历史版本的数据）

2. 读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁

3. 加锁的 SELECT，或者对数据进行增删改都会进行当前读

4. 比如如下SQL都是当前读：

   SELECT * FROM student LOCK IN SHARE MODE; # 共享锁
   SELECT * FROM student FOR UPDATE; # 排他锁
   INSERT INTO student values ... # 排他锁
   DELETE FROM student WHERE ... # 排他锁
   UPDATE student SET ... # 排他锁

原理

undo日志版本链和隐藏字段

对于InnoDB 存储引擎的表来说，为了保证其事务原子性并且多个事务之间的数据可以回滚，提供了undo日志版本链。在undo日志版本链中，链中的每一条日志都记录每次修改的记录的信息。

image-20220317144736294

1. trx_id：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的 事务id 赋值给trx_id隐藏列

2. roll_pointer ：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到 undo日志 中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息。

上图表示这条记录被事务id为8的事务获取修改，并且具有一个undo日志指向一个Insert undo 日志。

假设有两个事务对这条记录进行修改，他们的事务id分别为10和20：

时间顺序	事务10	事务20
1	BEGIN;
2		BEGIN;
3	UPDATE student SET name="李四" WHERE id=1;
4	UPDATE student SET name="王五" WHERE id=1;
5	COMMIT;
6		UPDATE student SET name="钱七" WHERE id=1;
		UPDATE student SET name="宋八" WHERE id=1;
		COMMIT;

那么每次修改都会记录改动，并且生成一个undo log链表：

image-20220317181440805

ReadView

在MVCC机制中，多个事务会对同一个行记录进行更新产生多个历史快照，这些快照会保存到Undo Log中。如果一个事务想要查询这个记录，需要读取哪个版本的行记录？这时候就需要ReadView，帮我们解决可见性的问题。

ReadView是事务在使用MVCC机制进行快照读操作产生的一种读视图。当事务启动时，会生成数据库当前的一个快照，InnoDB为每个事务构造了一个数组，用来记录并维护系统当前活跃事务的ID。