MySQL事务

MySQL的InnoDB存储引擎,是通过事务来保证数据的一致性的。
数据库事务通常包含了一个序列的对数据库的读/写操作。为数据库操作序列提供了一个从失败中恢复到正常状态的方法,同时提供了数据库即使在异常状态下仍能保持一致性的方法。

特性

事务的四个特性ACID。分别是原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。

  • 原子性(Automicity):事务作为一个 整体被执行,包含在其中的对数据库的操作要么全部被执行,要么都不执行。
  • 一致性(Consistency):事务应确保数据库的状态从一个一致状态转变为另一个一致状态。一致状态的含义是数据库中的数据应满足完整性约束。一致性是说无论事务提交还是回滚,不会破环数据的完整性。比如A给B转100元,如果成功了,A的账户必定会扣100,而B的账户必定会增加100元;如果失败了,A和B的账户余额不会改变。不会存在其他的情况,这样就是符合一致性的。事实上,原子性、持久性和隔离性都是为了保证一致性。
  • 隔离性(Isolation):多个事务并发执行时,一个事务的执行不应影响其他事务的执行。
  • 持久性(Durability):已被提交的事务对数据库的修改应该永久保存在数据库中。
原子性

事务的原子性是指:一个事务中的多个操作都是不可分割的,只能是全部执行成功、或者全部执行失败。
MySQL事务的原子性是通过undo log来实现的。undo log是InnoDB存储引擎特有的。具体的实现方法是:将所有对数据库的修改(增、删、改)都写入日志(undo log)。如果一个事务中的一部分操作已经成功,但另一部分操作,由于断电/系统崩溃/其它的软硬件错误而无法成功执行,则通过回溯日志,将已经执行成功的操作撤销,从而达到全部操作失败的目的。
undo log是逻辑日志,可以理解为:记录和事务操作相反的SQL语句,事务执行insert语句,undo log就记录delete语句。它以追加写的方式记录日志,不会覆盖之前的日志。除此之外undo log还用来实现数据库多版本并发控制(Multiversion Concurrency Control,简称MVCC)。

持久性

事务的持久性是指:一个事务对数据库的所有修改,都会永久的保存在数据库中。
MySQL事务的持久性是通过redo log来实现的。redo log也是InnoDB存储引擎特有的。具体的实现方式是:当发生数据修改(增、删、改)的时候,InnoDB引擎会先将记录写道redo log中,并更新内存,此时更新就算完成了。同时InnoDB引擎会在合适的时机将记录刷到磁盘中。
redo log是物理日志,记录的是在某个数据页做了什么修改,而不是SQL语句的形式。它有固定大小,是循环写的方式记录日志,空间用完后会覆盖之前的日志。
undo log和redo log并不是直接写到磁盘上的,而是先写入log buffer。再等待合适的时机同步到OS buffer,再由操作系统决定何时刷到硬盘,具体过程如下:
MySQL事务_第1张图片
既然undo log和redo log都是从log buffer到OS buffer,再到磁盘,所以中途还是有可能因为断电/硬件故障等原因导致日志丢失。为此MySQL提供了三种持久化方式。innoDB_flush_log_at_trx_commit这个参数主要控制InnoDB将log buffer中的数据写入OS buffer,并刷到磁盘的时间点,取值分别为0,1,2,默认值是1。这三个值的意思分别如下:
MySQL事务_第2张图片
MySQL默认设置的方式1,也就是每次提交后直接写入OS buffer,并且调用系统函数fsync()把日志写到硬盘上。就保证数据一致性的角度来说,这种方式无疑是最安全的。但是安全大多数时候意味着效率偏低。每次提交都直接写入OS buffer并写到磁盘,无疑会导致单位时间内IO的次数过多而效率低下。除此之外,还有方式0和方式2。基本上都是每秒写入磁盘一次,所以效率都比方式1更高。但是方式0是把数据先写入log buffer再写入OS buffer再写入磁盘,而方式2是直接写入OS buffer,再写入磁盘,少了一次数据拷贝的过程(从log buffer到OS buffer),所以方式2比方式0更加效率。
数据库系统崩溃后重启,此时数据库处于不一致的状态,必须先执行一个crash recovery的过程:首先读取redo log,把成功提交但是还没来得及写入磁盘的数据重新写入磁盘,保证了持久性。再读取undo log将还没有成功提交的事务进行回滚,保证了原子性。crash recovery结束后,数据库恢复到一致性状态,可以继续被使用。

隔离性

数据库事务的隔离性是指:多个事务并发执行时,一个事务的执行并不应影响其他事务的执行。正常情况下,肯定是多个事务同时操作同一个数据库,所以事务之间的隔离就显得必不可少。
如果没有隔离性,会发生哪些问题?

第一类丢失更新

第一类丢失更新是指:一个事务在撤销的时候,覆盖了另一个事务已提交的更新数据。
假设事务A和事务B操作同一个账户的金钱:

时间 事务A 事务B
T1 开启事务 开启事务
T2 查询账户余额:500元 查询账户余额:500元
T3 取出100元,剩余400元 取出100元,剩余400元
T4 提交事务,账户余额:400元 -
T5 - 撤销事务,账户余额:500元

事务B在撤销事务的时候,覆盖了事务A在T4的时候已经提交的更新数据。A在T3的时候已经取走了100元,此时的余额应该是400元,但是由于事务B开始的时候,余额是500元,所以回滚后,余额也会变成500元。

脏读

脏读:一个事务读到了另一个事务未提交的更新数据。

时间 事务A 事务B
T1 开启事务 开启事务
T2 查询账户余额:500元 -
T3 取出100元,剩余400元 -
T4 - 查询余额:400元
T5 撤销事务,账户余额:500元 -

事务A在T3的时候取走了400元,但是未提交。事务B在T4时查询余额就能看到事务A未提交的更新。

幻读

幻读(虚读)是指:一个事务读到了另一个事务已提交的新增数据。

时间 事务A 事务B
T1 开启事务 开启事务
T2 - 执行select count统计
T3 新增一条数据 -
T4 提交事务 -
T5 - 执行select count统计

事务B在同一个事务中执行两次统计操作,得到的结果不一样。

不可重复读

不可重复读:一个事务读到了另一个事务已提交的更新数据。

时间 事务A 事务B
T1 开启事务 开启事务
T2 查询余额:500元 查询余额:500元
T3 取走100元,剩余:400元 -
T4 提交事务 -
T5 - 查询余额:400元

事务B在同一个事务中,两次读取余额,得到的结果却不一样。

第二类丢失更新

第二类丢失更新是指:一个事务在提交的时候,覆盖了另一个事务已提交的更新数据。

时间 事务A 事务B
T1 开启事务 开启事务
T2 查询余额:500元 查询余额:500元
T3 取走100元,剩余:400元 取走100元,剩余:400元
T4 提交事务,账户余额:400元 -
T5 - 提交事务,账户余额:400元

事务A和事务B分别取了100元,所以余额应该为300元。但是事务B在提交的时候,覆盖了事务A已经提交的更新数据,所以导致结果出错。

为了解决这五类问题,MySQL提供了四种隔离级别
  • Serializable(串行化):事务之间以一种串行的方式执行,安全性非常高,效率低。
  • Repeatable Read(可重复读):是MySQL默认的隔离级别,同一个事务中相同的查询会看到同样的数据行,安全性较高,效率较好。
  • Read Commited(读已提交):一个事务可以读取到另一个事务已经提交的数据,安全性较低,效率较高。
  • Read Uncommited(读未提交):一个事务可以读取到另外一个事务未提交的数据,安全性低,效率高。
    隔离级别与并发性能的关系图如下:
    MySQL事务_第3张图片
    需要注意的是,除了Serializable能完完全全的解决这五类问题之外,其余的三种隔离级别都不能完全解决这五类问题。各种隔离级别能解决
    的问题对应如下
隔离级别 是否出现第一类丢失更新 是否出现脏读 是否出现虚读 是否出现不可重复读 是否出现第二类丢失更新
Serializable
Repeatable Read
Read Commit
Read Uncommited
Repeatablee Read

Repeatable Read(可重复读)是MySQL默认的隔离级别,也是使用最多的隔离级别。Reportable Read无法解决虚读(幻读)问题。下面来看一个实例

# 建表
CREATE TABLE student  (
  id int(4) primary key auto_increment,
  name varchar(10)
) ENGINE = InnoDB;

# 插入一条数据
insert into student(name) values('zhangsan');

开启连个操作窗口,均关闭自动提交set autocommit = 0,其余的操作的时间线如下:

时间 事务A 事务B
T1 select * from student -
T2 - insert into student(name) values (‘lisi’)
T3 - commit
T4 select * from student -

按照上述理论,会出现幻读现象。也就是事务A的第二次select会看到事务B提交的新增数据。
执行结果如下:

mysql> select * from student;
+----+----------+
| id | name     |
+----+----------+
|  1 | zhangsan |
+----+----------+
1 row in set (0.00 sec)

和预期的结果并不一致,没有出现幻读现象。
实际上MySQL在Repeatable Read隔离级别下,用MVCC(Multiversion Concurrency Control,多版本控制器)解决了select普通查询的幻读现象。
具体的实现方式就是事务开始时,第一条select语句查询结果集会生成一个快照(snapshot),并且这个事务结束前,同样的select语句返回的都是这个快照的结果,而不是最新的查询结果,这就是MySQL在Repeatable Read隔离级别对普通select语句使用的快照读(snapshot read)。

快照读和MVCC是什么关系?

MVCC是多版本并发控制,快照就是其中的一个版本。所以可以说MVCC实现了快照读,具体的实现方式涉及到MySQL的隐藏列。
MySQL会给每个表自动创建三个隐藏列:

  • DB_TRX_ID:事务ID,记录操作(增、删、改)该数据事务的事务ID
  • DB_ROLL_PTR:回滚指针,记录上一个版本的数据在undo log中的位置。
  • DB_ROW_ID:隐藏ID,创建表没有合适的索引作为聚簇索引时,会用该隐藏ID创建聚簇索引。
    由于undo log中记录了各个版本的数据,并且通过DB_ROLL_PTR可以找到各个历史版本,并且由DB_TRX_ID决定使用哪个版本(快照)。所以相当于undo log实现了MVCC,MVCC实现了快照读。
    如此看来,MySQL的Repeatable Read隔离级别利用快照读,已经解决了幻读的问题。但是事实并非如此,接下来再看一个例子。
    继续上面的操作(注意:开始前,先提交上一次操作的事务)
时间 事务A 事务B
T1 select * from student -
T2 - insert into student(name) values (‘wangwu’)
T3 - commit
T4 update student set name = ‘zhaoliu’ where name = ‘wangwu’ -
T5 select * from student -

事务A在T1的时候生成快照,事务B在T2的时候插入一条数据wangwu,然后提交。在T4的时候把wabgwu更新成zhaoliu,根据上一个例子,此时事务A是看不到wangwu这条数据的,所以更新也不会成功,并且在T5的时候查询,和T1时候一样,只有zhangsan和lisi两条数据。
执行结果如下:

mysql> select * from student;
+----+----------+
| id | name     |
+----+----------+
|  1 | zhangsan |
|  2 | lisi     |
|  3 | zhaoliu  |
+----+----------+
3 rows in set (0.00 sec)

但是执行结果却不是预期的那样,事务A不仅看到了wangwu,还把它成功的改成了zhaoliu。即使事务A成功commit之后,再次查询还是这样。
这其实时MySQL对insert、update和delete语句所使用的当前读(current read)。因为涉及到数据的修改,所以MySQL必须拿到最新的数据才能修改,所以涉及到数据的修改肯定不能使用快照读(snapshot read)。由于事务A读到了事务B已提交的新增数据,所以就产生了前文所说的幻读。

那么在Reportable Read隔离级别是怎么解决幻读的呢?

是通过间隙锁(Gap Lock)来解决的。InnoDB支持行级锁,并且行锁时锁住索引。而间隙锁是用来锁定索引记录间隙,确保索引记录的间隙不变。间隙锁是针对事务的隔离级别为Reportable Read或以上级别而已的,间隙锁和行锁一起组成了Next-Key Lock。当InnoDB扫描索引记录的时候,会首先对索引记录加上行级锁,再对索引记录两边的间隙加上间隙锁(Gap Lock)。加上间隙锁之后,其他事务就不能在这个间隙插入记录。这样就有效的防止了幻读的发生。
默认情况下,InnoDB工作在Repeatable Read的隔离级别下,并且以Next-Key Lock的方式对索引行进行加锁。当查询的索引具有唯一性(主键、唯一索引)时,InnoDB存储引擎会对Next-Key Lock进行优化,将其降为行锁,仅仅锁住索引本身,而不是范围(除非锁定不存在的值)。若是普通索引,则会使用Next-Key Lock将记录和间隙一起锁定。

  • 使用快照读的语句
select * from ...

  • 使用当前读的语句
select * from ... lock in share mode
select * from ... for update
insert into table...
update table set ...
delete table where ...
总结

本文主要讲解了MySQL事务的ACID四大特性、undo log和redo log分别实现了原子性和持久性、log持久化的三种方式、数据库并发下的五类问题、四种隔离级别、RR隔离级别下select幻读通过MVCC解决、select … lock in share mode/select … for update/insert/update/delete的幻读是通过间隙锁来解决。

你可能感兴趣的:(MySQL事务)