杨顺翔的技术驿站
Github

事务

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

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

使用事务

  1. 显示开启事务

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

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

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

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

事务的状态

事务的四个属性

  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：

查询/设置隔离级别

查询隔离级别：

-- 查看隔离级别，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。

redo日志（持久性）

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

整个过程：

  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) ，保存在内存中，是易失的。 （下图是一个连续存储结构）

    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进行一次重做日志的同步）

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

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

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的多个文件。

整体结构与流程

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

  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");

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

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

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

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

UPDATE user SET id=2 WHERE id=1;

怎么保证事务的一致性？

从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性。也就是说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日志版本链中，链中的每一条日志都记录每次修改的记录的信息。

  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链表：

ReadView

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

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

上一页锁机制下一页Mysql函数总结

最后更新于