一基础概念
事务(Transaction)是访问和更新数据库的程序执行单元;
事务中可能包含一个或多个sql语句,这些语句要么都执行,
要么都不执行。作为一个关系型数据库,MySQL支持事务,本文介绍基于MySQL5.6。
mysql事务的基础知识
逻辑架构和存储引擎
如上图所示,MySQL服务器逻辑架构从上往下可以分为三层:
(1)第一层:处理客户端连接、授权认证等。
(2)第二层:服务器层,负责查询语句的解析、优化、缓存以及内置函数的实现、存储过程等。
(3)第三层:存储引擎,负责MySQL中数据的存储和提取。MySQL中服务器层不管理事务,事务是由存储引擎实现的。MySQL支持事务的存储引擎有InnoDB、NDB Cluster等,其中InnoDB的使用最为广泛;其他存储引擎不支持事务,如MyIsam、Memory等。
如无特殊说明,后文中描述的内容都是基于InnoDB。
2、提交和回滚
典型的MySQL事务是如下操作的:
tart transaction;
…… #一条或多条sql语句
commit;
其中start transaction标识事务开始,commit提交事务,将执行结果写入
到数据库。如果sql语句执行出现问题,会调用rollback,
回滚所有已经执行成功的sql语句。当然,也可以在事务中直接
使用rollback语句进行回滚。
自动提交
MySQL中默认采用的是自动提交(autocommit)模式
mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | ON |
+---------------+-------+
1 row in set (0.01 sec)
在自动提交模式下,如果没有start transaction显式地开始一个事务,那么每个sql语句都会被当做一个事务执行提交操作。
通过如下方式,可以关闭autocommit;需要注意的是,autocommit参数是针对连接的,在一个连接中修改了参数,不会对其他连接产生影响。
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | OFF |
+---------------+-------+
1 row in set (0.00 sec)
如果关闭了autocommit,则所有的sql语句都在一个事务中,
直到执行了commit或rollback,该事务结束,同时开始了另外一个事务。
特殊操作
在MySQL中,存在一些特殊的命令,如果在事务中执行了这些命令,
会马上强制执行commit提交事务;
如DDL语句(create table/drop table/alter/table)、
lock tables语句等等。常用的select、insert、update和delete命令,
都不会强制提交事务。
3、ACID特性
ACID是衡量事务的四个特性:
-
原子性(Atomicity,或称不可分割性)
-
一致性(Consistency)
-
隔离性(Isolation)
-
持久性(Durability)
按照严格的标准,只有同时满足ACID特性才是事务; 但是在各大数据库厂商的实现中,真正满足ACID的事务少之又少。 例如MySQL的NDB Cluster事务不满足持久性和隔离性; InnoDB默认事务隔离级别是可重复读,不满足隔离性; Oracle默认的事务隔离级别为READ COMMITTED, 不满足隔离性……因此与其说ACID是事务必须满足的条件, 不如说它们是衡量事务的四个维度。
二 、原子性
-
定义
原子性是指一个事务是一个不可分割的工作单位,其中的操作要么都做, 要么都不做;如果事务中一个sql语句执行失败, 则已执行的语句也必须回滚,数据库退回到事务前的状态。
-
实现原理:undo log
在说明原子性原理之前,首先介绍一下MySQL的事务日志。MySQL的日 志有很多种,如二进制日志、错误日志、查询日志、慢查询日志等,此外 InnoDB存储引擎还提供了两种事务日志:redo log(重做日志)和undo log(回滚日志)。其中redo log用于保证事务持久性;undo log则是事务原 子性和隔离性实现的基础。 下面说回undo log。实现原子性的关键,是当事务回滚时能够撤销所有已 经成功执行的sql语句。InnoDB实现回滚,靠的是undo log:当事务对数 据库进行修改时,InnoDB会生成对应的undo log;如果事务执行失败或 调用了rollback,导致事务需要回滚,便可以利用undo log中的信息将数 据回滚到修改之前的样子。 undo log属于逻辑日志,它记录的是sql执行相关的信息。当发生回滚 时,InnoDB会根据undo log的内容做与之前相反的工作:对于每个 insert,回滚时会执行delete;对于每个delete,回滚时会执行insert;对 于每个update,回滚时会执行一个相反的update,把数据改回去。 以update操作为例:当事务执行update时,其生成的undo log中会包含被 修改行的主键(以便知道修改了哪些行)、修改了哪些列、这些列在修改前 后的值等信息,回滚时便可以使用这些信息将数据还原到update之前的 状态。
三、持久性
-
定义
持久性是指事务一旦提交,它对数据库的改变就应该是永久性的。接下来 的其他操作或故障不应该对其有任何影响。
-
实现原理:redo log
redo log和undo log都属于InnoDB的事务日志。下面先聊一下redo log存 在的背景。 InnoDB作为MySQL的存储引擎,数据是存放在磁盘中的,但如果每次读写数据 都需要磁盘IO,效率会很低。为此,InnoDB提供了缓存(Buffer Pool),Buffer Pool中包含了磁盘中部分数据页的映射,作为访问数据库的缓冲:当从数据库 读取数据时,会首先从Buffer Pool中读取,如果Buffer Pool中没有,则从磁盘读 取后放入Buffer Pool;当向数据库写入数据时,会首先写入Buffer Pool,Buffer Pool中修改的数据会定期刷新到磁盘中(这一过程称为刷脏)。 Buffer Pool的使用大大提高了读写数据的效率,但是也带了新的问题:如果 MySQL宕机,而此时Buffer Pool中修改的数据还没有刷新到磁盘,就会导致数 据的丢失,事务的持久性无法保证。 于是,redo log被引入来解决这个问题:当数据修改时,除了修改Buffer Pool中 的数据,还会在redo log记录这次操作;当事务提交时,会调用fsync接口对redo log进行刷盘。如果MySQL宕机,重启时可以读取redo log中的数据,对数据库 进行恢复。redo log采用的是WAL(Write-ahead logging,预写式日志),所有 修改先写入日志,再更新到Buffer Pool,保证了数据不会因MySQL宕机而丢 失,从而满足了持久性要求。 既然redo log也需要在事务提交时将日志写入磁盘,为什么它比直接将Buffer Pool中修改的数据写入磁盘(即刷脏)要快呢?主要有以下两方面的原因: (1)刷脏是随机IO,因为每次修改的数据位置随机,但写redo log是追加操 作,属于顺序IO。 (2)刷脏是以数据页(Page)为单位的,MySQL默认页大小是16KB,一个 Page上一个小修改都要整页写入;而redo log中只包含真正需要写入的部分,无 效IO大大减少。
-
redo log与binlog
我们知道,在MySQL中还存在binlog(二进制日志)也可以记录写操作并用于数据 的恢复,但二者是有着根本的不同的:
(1)作用不同:redo log是用于crash recovery的,保证MySQL宕机也不会影响持久性;binlog是用于point-in-time recovery的,保证服务器可以基于时间点恢复数据,此外binlog还用于主从复制。
(2)层次不同:redo log是InnoDB存储引擎实现的,而binlog是MySQL的服务器层(可以参考文章前面对MySQL逻辑架构的介绍)实现的,同时支持InnoDB和其他存储引擎。
(3)内容不同:redo log是物理日志,内容基于磁盘的Page;binlog的内容是二进制的,根据binlog_format参数的不同,可能基于sql语句、基于数据本身或者二者的混合。
(4)写入时机不同:binlog在事务提交时写入;redo log的写入时机相对多元:
前面曾提到:当事务提交时会调用fsync对redo log进行刷盘;这是默认情况下的策略,修改
innodb_flush_log_at_trx_commit参数可以改变该策略,但事务的持久性将无法保证。
除了事务提交时,还有其他刷盘时机:如master thread每秒刷盘一次redo log等,
这样的好处是,不一定要等到commit时刷盘,commit速度大大加快。
四、隔离性
-
定义
与原子性、持久性侧重于研究事务本身不同,隔离性研究的是不同事务之间的 相互影响。隔离性是指,事务内部的操作与其他事务是隔离的,并发执行的各 个事务之间不能互相干扰。严格的隔离性,对应了事务隔离级别中Serializable (可串行化),但实际应用中出于性能方面的考虑很少会使用可串行化。 隔离性追求的是并发情形下事务之间互不干扰。简单起见,我们仅考虑最简单 的读操作和写操作(暂时不考虑带锁读等特殊操作),那么隔离性的探讨,主要可 以分为两个方面: 1. (一个事务)写操作对(另一个事务)写操作的影响:锁机制保证隔离性 2. (一个事务)写操作对(另一个事务)读操作的影响:MVCC保证隔离性
-
锁机制
首先来看两个事务的写操作之间的相互影响。隔离性要求同一时刻只能有一个 事务对数据进行写操作,InnoDB通过锁机制来保证这一点。 锁机制的基本原理可以概括为:事务在修改数据之前,需要先获得相应的锁; 获得锁之后,事务便可以修改数据;该事务操作期间,这部分数据是锁定的, 其他事务如果需要修改数据,需要等待当前事务提交或回滚后释放锁。
行锁与表锁
按照粒度,锁可以分为表锁、行锁以及其他位于二者之间的锁。表锁在操作数据时会锁定整张
表,并发性能较差;行锁则只锁定需要操作的数据,并发性能好。但是由于加锁本身需要消耗
资源(获得锁、检查锁、释放锁等都需要消耗资源),因此在锁定数据较多情况下使用表锁可以
节省大量资源。MySQL中不同的存储引擎支持的锁是不一样的,例如MyIsam只支持表锁,而
InnoDB同时支持表锁和行锁,且出于性能考虑,绝大多数情况下使用的都是行锁。
如何查看锁信息
有多种方法可以查看InnoDB中锁的情况,例如:
select * from information_schema.innodb_locks; #锁的概况
show engine innodb status; #InnoDB整体状态,其中包括锁的情况
试验
事务1
mysql> start transaction; 操作1
Query OK, 0 rows affected (0.00 sec)
mysql> update user set name='cdb1' where id=19 ; 操作2
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> select * from information_schema.innodb_locks; 操作5
+---------------+-------------+-----------+-----------+----------------+------------+------------+-----------+----------+-----------+
| lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
+---------------+-------------+-----------+-----------+----------------+------------+------------+-----------+----------+-----------+
| 34749:354:3:2 | 34749 | X | RECORD | `study`.`user` | PRIMARY | 354 | 3 | 2 | 19 |
| 34748:354:3:2 | 34748 | X | RECORD | `study`.`user` | PRIMARY | 354 | 3 | 2 | 19 |
+---------------+-------------+-----------+-----------+----------------+------------+------------+-----------+----------+-----------+
事务2 执行
mysql> start transaction; 操作3
Query OK, 0 rows affected (0.00 sec)
mysql> update user set name='cdb2' where id=19; 操作4
-- 等待锁释放
此时在事务1中执行操作5 查看锁情况
通过上述命令可以查看事务34749和34748占用锁的情况;其中lock_type为RECORD,代表锁为
行锁(记录锁);lock_mode为X,代表排它锁(写锁)。
除了排它锁(写锁)之外,MySQL中还有共享锁(读锁)的概念。其他篇幅
-
脏读、不可重复读和幻读
-
事务隔离级别
3、4 见 mysql事务处理-四种隔离级别 -
mvcc
RR(可重复读)解决脏读、不可重复读、幻读等问题,使用的是MVCC:MVCC全称 Multi-Version Concurrency Control,即多版本的并发控制协议。 下面的例子很好的体现了MVCC的特点: 在同一时刻,不同的事务读取到的数据可能是不同的(即多版本)——在T5时刻, 事务A和事务C可以读取到不同版本的数据。
MVCC最大的优点是读不加锁,因此读写不冲突,并发性能好。InnoDB实现 MVCC,多个版本的数据可以共存,主要是依靠数据的隐藏列(也可以称之为标 记位)和undo log。其中数据的隐藏列包括了该行数据的版本号、删除时间、指 向undo log的指针等等;当读取数据时,MySQL可以通过隐藏列判断是否需要 回滚并找到回滚需要的undo log,从而实现MVCC,隐藏列的详细格式不再展开。
下面结合前文提到的几个问题分别说明。
- 总结
1)脏读
当事务A在T3时间节点读取zhangsan的余额时,会发现数据已被其他事务修改,且状态为未提
交。此时事务A读取最新数据后,根据数据的undo log执行回滚操作,得到事务B修改前的数
据,从而避免了脏读。
不可重复读
当事务A在T2节点第一次读取数据时,会记录该数据的版本号(数据的版本号是以row为单位记录
的),假设版本号为1;当事务B提交时,该行记录的版本号增加,假设版本号为2;当事务A在T5
再一次读取数据时,发现数据的版本号(2)大于第一次读取时记录的版本号(1),因此会根据
undo log执行回滚操作,得到版本号为1时的数据,从而实现了可重复读。
3)幻读
InnoDB实现的RR通过next-key lock机制避免了幻读现象。
next-key lock是行锁的一种,实现相当于record lock(记录锁) + gap lock(间隙锁);其特点是不
仅会锁住记录本身(record lock的功能),还会锁定一个范围(gap lock的功能)。当然,这里我们
讨论的是不加锁读:此时的next-key lock并不是真的加锁,只是为读取的数据增加了标记(标
记内容包括数据的版本号等);准确起见姑且称之为类next-key lock机制。还是以前面的例子
来说明:
当事务A在T2节点第一次读取0<id<5数据时,标记的不只是id=1的数据,而是将范围(0,5)进行了
标记,这样当T5时刻再次读取0<id<5数据时,便可以发现id=4的数据比之前标记的版本号更高,
此时再结合undo log执行回滚操作,避免了幻读。
-
总结
概括来说,InnoDB实现的RR,通过锁机制、数据的隐藏列、undo log和类next- key lock,实现了一定程度的隔离性,可以满足大多数场景的需要。不过需要说 明的是,RR虽然避免了幻读问题,但是毕竟不是Serializable,不能保证完全的 隔离,下面是一个例子,大家可以自己验证一下。
五、一致性
-
基本概念
一致性是指事务执行结束后,数据库的完整性约束没有被破坏,事务执行的前后 都是合法的数据状态。数据库的完整性约束包括但不限于:实体完整性(如行的 主键存在且唯一)、列完整性(如字段的类型、大小、长度要符合要求)、外键 约束、用户自定义完整性(如转账前后,两个账户余额的和应该不变)。
-
实现
可以说,一致性是事务追求的最终目标:前面提到的原子性、持久性和隔离 性,都是为了保证数据库状态的一致性。此外,除了数据库层面的保障,一致 性的实现也需要应用层面进行保障。 实现一致性的措施包括: 1. 保证原子性、持久性和隔离性,如果这些特性无法保证,事务的一致性也 法保证 2. 数据库本身提供保障,例如不允许向整形列插入字符串值、字符串长度不能 超过列的限制等 3. 应用层面进行保障,例如如果转账操作只扣除转账者的余额,而没有增加接 收者的余额,无论数据库实现的多么完美,也无法保证状态的一致
六、总结
下面总结一下ACID特性及其实现原理:
- 原子性:语句要么全执行,要么全不执行,是事务最核心的特性,事务本身就是以原子性来定义的;实现主要基于undo log
- 持久性:保证事务提交后不会因为宕机等原因导致数据丢失;实现主要基于redo log
- 隔离性:保证事务执行尽可能不受其他事务影响;InnoDB默认的隔离级别是RR,RR的实现主要基于锁机制、数据的隐藏列、undo log和类next-key lock机制
- 一致性:事务追求的最终目标,一致性的实现既需要数据库层面的保障,也需要应用层面的保障