Mysql 事务及其原理

时间:2019-09-17
本文章向大家介绍Mysql 事务及其原理,主要包括Mysql 事务及其原理使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

Mysql 事务及其原理

什么是事务

什么是事务?事务是作为单个逻辑工作单元执行的一系列操作,通俗易懂的说就是一组原子性的 SQL 查询。Mysql 中事务的支持在存储引擎层,MyISAM 存储引擎不支持事务,而 InnoDB 支持,这是 Mysql 5.5.5 以后默认引擎由 MyISAM 换成 InnoDB 的最根本原因。

事务的 ACID 属性

原子性(Atomicity):作为逻辑工作单元,一个事务里的所有操作的执行,要么全部成功,要么全部失败。

一致性(Consistency):数据库从一个一致性状态变换到另外一个一致性状态,数据库的完整性不会受到破坏。

隔离性(Isolation):通常来说,一个事务所做的修改在最终提交前,对其他事务是不可见的。为什么是通常来说,为了提高事务的并发引出不同的隔离级别,具体参考下一章节。

持久性(Durability):一旦事务提交,则其所做的修改就会永久保存到数据库中,即使系统故障,修改的数据也不会丢失。

事务的隔离级别

为了尽可能的高并发,事务的隔离性被分为四个级别:读未提交、读已提交、可重复读和串行化。用户可以根据需要选择不同的级别。

未提交读(READ UNCOMMITTED):一个事务还未提交,它的变更就能被别的事务看到。

例:事务 A 可以读到事务 B 修改的但还未提交的数据,会导致脏读(可能事务 B 在提交后失败了,事务 A 读到的数据是脏的)。

提交读(READ COMMITTED):一个事务提交后,它的变更才能被其他事务看到。大多数据库系统的默认级别,但 Mysql 不是。

例:事务 A 只能读到事务 B 修改并提交后的数据,会导致不可重复读(事务 A 中执行两次查询,一次在事务 B 提交过程中,一次在事务 B 提交之后,会导致两次读取的结果不一致)。

可重复读(REPEATABLE READ):未提交的事务的变更不能被其他事务看到,同时一次事务过程中多次读取同样记录的结果是一致的。 例:事务 A 在执行过程中多次获取某范围内的记录,事务 B 提交后在此范围内插入或者删除 N条记录,事务 A 执行过程中多次范围读会存在不一致,即幻读(Mysql 的默认级别,InnoDB 通过 MVVC 解决了幻读的问题)。

可串行化(SERIALIZABLE):当两个事务间存在读写冲突时,数据库通过加锁强制事务串行执行,解决了前面所说的所有问题(脏读、不可重复读、幻读)。是最高隔离的隔离级别。

用表格可以更清晰的描述四种隔离级别的定义和可能存在的问题:

以上是对四种隔离级别的定义和初步认识,《十分钟搞懂MySQL四种事务隔离级别 》这篇文章中有动图可以彻底弄明白隔离级别。

Mysql 中的事务

1、事务的自动提交

Mysql 默认采用自动提交(AUTOCOMMIT)模式,也就是说,如果不显示地开始一个事务,则每个查询都被当做一个事务执行提交操作。 可以通过以下命令查看 mysql 是否打开自动提交,

mysql> show variables like 'AUTOCOMMIT';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit    | ON    |
+---------------+-------+
1 row in set (0.01 sec)
--1 或者 ON 表示启用, 0 或者 OFF 表示禁用
mysql> SET AUTOCOMMIT = 0/1; 
--以上命令可以打开和关闭自动提交

1、通过 set autocommit = 0 关闭当前会话的自动提交,如果需要对全局生效必须再配置文件中进行修改。

2、关闭自动提交后,用户的所有 DML 语句都会在同一个事务中,直到遇到 COMMIT 或 ROLLBACK 指令结束事务。

一张动图来说明以上两点:

当然,用户可以通过 start transaction 或者 begin 显示的开启一个事务。**显示的开启事务会自动执行 set autocommit = 0,并在 commit 或 rollback 结束一个事务后执行 set autocommit = 1。**更多事务的控制语句如下:

START TRANSACTION | BEGIN: 显式地开启一个事务;
COMMIT:也可以使用 COMMIT WORK,不过二者是等价的。COMMIT 会提交事务,并使已对数据库进行的所有修改成为永久性的;
ROLLBACK:也可以使用 ROLLBACK WORK,不过二者是等价的。回滚会结束用户的事务,并撤销正在进行的所有未提交的修改;
SAVEPOINT identifier:SAVEPOINT 允许在事务中创建一个保存点,一个事务中可以有多个 SAVEPOINT;
RELEASE SAVEPOINT identifier:删除一个事务的保存点,当没有指定的保存点时,执行该语句会抛出一个异常;
ROLLBACK TO identifier:把事务回滚到标记点;
SET TRANSACTION:用来设置事务的隔离级别。

2、事务的隔离级别

Mysql 支持事务最流行的存储引擎非 InnoDB 莫属,所以以下的 Mysql 隔离级别设置都是基于 InnoDB 的。

1、查看InnoDB存储引擎系统级的隔离级别和会话级的隔离级别,命令和结果如下:

mysql> select @@global.tx_isolation,@@tx_isolation;
+-----------------------+-----------------+
| @@global.tx_isolation | @@tx_isolation  |
+-----------------------+-----------------+
| REPEATABLE-READ       | REPEATABLE-READ |
+-----------------------+-----------------+

2、设置InnoDB存储引擎隔离级别:

语句:

set [ global | session ] transaction isolation level Read uncommitted | Read committed | Repeatable | Serializable;

示例:

mysql> set session  transaction isolation level Serializable;
Query OK, 0 rows affected (0.01 sec)

mysql> select @@global.tx_isolation,@@tx_isolation;
+-----------------------+----------------+
| @@global.tx_isolation | @@tx_isolation |
+-----------------------+----------------+
| REPEATABLE-READ       | SERIALIZABLE   |
+-----------------------+----------------+
1 row in set (0.00 sec)

3、事务的 MVCC 机制

Mysql 的事务型存储引擎(InnoDB)使用 MVCC(Multi-Version Concurrency Control,多版本并发控制)代替行级锁来提高并发读写的性能。InnoDB 的 MVCC 原理比较简单,它通过在在每行记录后面保存三个隐藏列(事务 id,行的创建的版本号、行的过期版本号)来实现的,下面是 InnoDB 在 REPEATABLE READ 隔离级别下 MVCC 的简化工作原理:

INSERT: InnoDB 为新插入的每一行保存当前系统版本号作为行版本号。

UPDATE: InnoDB为插入一行新记录,保存当前系统版本号作为行版本号,同时保存当前系统版本号到原来的行作为行删除标识。

DELETE: InnoDB为删除的每一行保存当前系统版本号作为行删除标识。

SELECT: InnoDB会根据以下两个条件检查每行记录:

  • InnoDB只查找版本早于当前事务版本的数据行(也就是,行的系统版本号小于或等于事务的系统版本号),这样可以确保事务读取的行,要么是在事务开始前已经存在的,要么是事务自身插入或者修改过的。
  • 行的删除版本要么未定义,要么大于当前事务版本号。这可以确保事务读取到的行,在事务开始之前未被删除。

只有符合上述两个条件的记录,才能返回作为查询结果。

下面用更浅显易懂的例子说明 MVCC 下的 INSERT/DELETE/UPDATE/SELECT 操作: 假如 test 表有两个字段 name 和 age;MVCC 的三个隐藏列字段名为 transaction_id、 create_version 和 delete_version。

insert

 
update 
 
delete
 
select 满足以下两个条件的记录才能被 select 读取出来:
  • delete_version 未定义或者大于 select 所在事务的 delete_version 的行。
  • create_version 小于或等于 select 所在事务的的 create_version。

通过这个例来看下为什么 MVCC 在 REPEATABLE READ 隔离级别下能解决幻读。假如有个事务开始于 update 之后 delete 之前,且结束于 delete 之后,如下:

start transaction;  //假如事务 id = 2.5
select * from test; //执行时间在 update 之后 delete 之前
select * from test; //执行时间在 delete 之后
commit;

如果不使用 MVCC 第一条 select * from test 能读到 1 条记录,而 第二条将读取到 0 条记录,同一事务中多次 select 范围查询读取到的记录不一致即幻读。而使用 MVVC 之后,两条 select 语句读取到的记录相同。

MVCC 只在 REPEATABLE READ 和 READ COMMITTED 两个隔离级别下工作。其他两个隔离级别都和MVCC不兼容,因为 READ UNCOMMITTED 总是读取最新的数据行,而不是符合当前事务版本的数据行。而 SERIALIZABLE 则会对所有读取的行都加锁。

4、事务的实现(redo/undo log)

事务的隔离性通过锁或 MVCC 机制来实现,而原子性、持久性和一致性通过 redo/undo log 来完成。redo log 称为重做日志,用来保证事务的原子性和持久性。undo log 称为撤销日志,用来保证事务的一致性。

1、redo log

基本概念

重做日志用来实现事务的持久性,由以下两部分组成:

  • 重做日志缓冲区(redo log buffer),内存中,易丢失。
  • 重做日志文件(redo log file),磁盘中,持久的。

redo log file 是顺序写入的,在数据库运行时不需要进行读取,只会在数据库启动的时候读取来进行数据的恢复工作。 redo log file 是物理日志,所谓的物理日志是指日志中的内容都是直接操作物理页的命令。重做时是对某个物理页进行相应的操作。

整体流程

更新事务操作一次数据的流程图如下所示:

  • 第一步:先将原始数据从磁盘中读入内存中来,修改数据的内存拷贝。

  • 第二步:生成一条重做日志并写入redo log buffer,记录的是数据被修改后的值。

  • 第三步:在必要的时候,采用追加写的方式将 redo log buffer 中的内容刷新到 redo log file。

  • 第四步:定期将内存中修改的数据刷新到磁盘中。

以上比较重要的是第三步,其中必要的时候有以下几种情况:

  • 事务提交时(最常见的情景,在 commit 之前)
  • 当 log buffer 中有一半的内存空间被使用时
  • log checkpoint 时
  • 实例 shutdown 时
  • binlog切换时
  • 后台线程

写入策略

学过 linux 操作系统的都知道内存中数据写入到磁盘文件中时如果不打开 O_DIRECT 选项。数据是要先写入文件操作系统缓存区中的,然后再某个时刻 flush 到磁盘。流程如下:

事务提交时将 redo log buffer 写入 redo log file,为了保证数据一定能正确同步到磁盘(不仅仅只写到文件缓冲区中)文件中,InndoDB 默认情况下调用了 fsync 进行写操作。而 fsync 的性能比较低。当然这只是默认情况,InnoDB 也提供了参数 innodb_flush_log_at_trx_commit 来配置 redo log 刷新到磁盘的策略,有以下三个值:

  • 当设置该值为 1 时,每次事务提交都要做一次 fsync,这是最安全的配置,即使宕机也不会丢失事务;
  • 当设置为 2 时,则在事务提交时只做 write 操作,只保证写到系统的缓冲区,因此实例crash不会丢失事务,但宕机则可能丢失事务;
  • 当设置为 0 时,事务提交不会触发 redo 写操作,而是留给后台线程每秒一次的刷盘操作,因此实例 crash 将最多丢失一秒钟内的事务。

用下图可以更直观的说明 innodb_flush_log_at_trx_commit 不同值下的不同策略。操作越接近磁盘性能越低,当然可靠性越来越高。故性能:1 < 2 < 0,可靠性:0 < 2 < 1。

当 innodb_flush_log_at_trx_commit 设置为 0 或者 2 时丧失了事务的 ACID 特性,通常在日常环境时将其设置为 1,而在系统高峰时将其设置为 2 以应对大负载。

恢复

InnoDB 引擎启动时不管上次数据库运行时是否正常关闭,都会尝试进行恢复操作。整个恢复操作有如下特点:

  • 从 checkpoint 开始的日志部分进行恢复。
  • 顺序读取及并行应用重做日志。
  • 重做日志的应用具有幂等性。
  • 重做日志是物理日志,恢复的速度相对较快。
2、undo log

基本概念

  • undo log 用来实现事务的一致性,InndoDB 可以通过 redo log 对页进行重做操作。但是有时候事务需要进行回滚,这时就需要 undo log。
  • undo log 还可可以用来协助 InnoDB 引擎实现 MVCC 机制。
  • undo log 是逻辑日志,恢复时并不是对物理页直接进行恢复,而是逻辑地将数据库恢复到原来的样子。
  • undo log 的产生也会伴随着 redo log 的产生。

写入时机

事务开始之前,流程如图:

日志格式

在 InnoDB 中 undo log 分为 insert undo log 和 update undo log

insert undo log

insert 操作产生的日志。根据隔离性,insert 插入的记录只对本事务可见,所以事务提交后可以删除因 insert 产生的日志。

update undo log

delete 和 update 操作产生的日志。根据前面的 MVCC 机制可以知道此部分记录还有可能要被其他事务所使用,所以即使事务提交也不能删除相应的日志。在事务提交时会被保存到 undo log 链表,在 purge 线程中做最后的删除。

3、redo 与 undo log 记录过程

undo 记录更新之前的日志,为了回滚。 redo 记录更新之后的日志,为了重做。 redo log 与 undo log 产生过程的简化版本如下,可以更方便的理解 redo 与 undo 的区别。

假设有A,B两个数据,原值分别为 1, 2;现将A更新为10,B 更新为 20;undo log记录信息过程如下:
1. 事务开始
2. 记录 A = 1 到 undo log
3. 更新 A = 10
4. 记录 A = 10 到 redo log
5. 记录 B = 2 到 undo log
6. 更新 B = 20
7. 记录 B = 20 到 redo log
8. redo log 信息写入磁盘
9. 提交事务

原文地址:https://www.cnblogs.com/weilingfeng/p/11531528.html