二.事务.

事务就是保证一组数据库操作，要么全部成功，要么全部失败。在MySQL中，事务支持是在引擎层实现的。MySQL是一个多引擎的系统，并不是所有的引擎都支持事务。

事务具有ACID属性（Atomicity,Consistency,Isolation,Durability；原子性，一致性，隔离性，持久性）。

当数据库上有多个事务同时执行的时候，就可能出现脏读，不可重复读，幻读的问题。为了解决这些问题，就有了隔离级别的概念。事务隔离级别包括读未提交(read uncommited)，读提交(read commited)，可重复读(repeatable read)，串行化(serializable)。

• 读未提交：一个事务还未提交时，它的修改就能被其他事务看到。
• 读已提交：一个事务提交后，它的修改才能被其他事务看到。
• 可重复读：一个事务在执行过程中看到的数据，总是跟这个数据在启动时看到的数据时一致的。
• 串行化：对一行记录，写会加锁，读也会加锁。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

create table t(c int) engine = InnoDB;
insert into t(c) values(1);

在不同的隔离级别下，V1，V2，V3会是不同的值。

如果隔离级别是read uncommited，V1是2。事务B还没提交，它的修改已经被事务A看到了。V2，V3都是2.

如果隔离级别是read commited，V1是1。V2，V3都是2

如果隔离级别是repeatable read，V1，V2是1，V3是2。遵循的要求就是：事务在执行期间看到的数据必须是前后一致的。

如果隔离级别是serialable，V1，V2是1，V3是2。事务B讲1改成2的时候，会被锁住。直到事务A提交后，事务B才可以继续执行。

Oracle数据库的默认隔离级别是read commited。

可重复读的场景：有一个统计账单的程序，统计过去一个月所有的账单。此时如果用户发生一笔新的交易，也不应该影响统计结果。这种场景下可以使用repeatable read。

“可重复读”隔离级别的实现

在MySQL中，实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。不同时刻启动的事务会有不同的read-view，图中可以看到，在视图A，B，C里面，这一个记录的值分别是1，2，4.同一个记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）。

对于可重复读隔离级别，事务T启动的时候会创建一个视图read-view，之后事务T执行期间，即使有其他事务修改了数据，事务T看到的仍然跟在启动时看到的一样。

MySQL事务的启动方式：

• 显式启动事务语句，begin或start transaction。配套的提交语句是commit，回滚语句是rollback。
• set autocommit=0,这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个select语句，这个事务就启动了，并且不会自动提交。这个事务存在直到主动commit或rollback语句，或者断开连接。

事务隔离

下面，我们举个例子来看看事务隔离级别。初始化一张表：

mysql> CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `k` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t(id, k) values(1,1),(2,2);

我们需要注意事务的启动时机，begin/start transaction并不是一个事务的起点，在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。如果要想马上启动一个事务，可以使用start transaction with consistent snapshot。

上面的流程图中，事务B查到的K的值是3，而事务A查到的K的值是1。

一致性读：虽然执行期间这一行数据被修改过，但是事务A不论在什么时候查询，看到的这行数据结果都是一致的，我们称之为一致性读。

对于一个事务视图来说，除了自己的更新总是可见之外，有三种情况：

1.版本未提交，不可见。

2.版本已提交，但是是在视图创建后提交的，不可见。

3.版本已提交，但是是在试图创建前提交的，可见。

在MySQL里面，有两个视图的概念：

• 一个是view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是create view …，而它的查询方法与表一样。
• 另一个是InnoDB在实现MVCC时用到的一致性读视图，即consistent read view，用于支持RC(read committed)和RR(repeated read)隔离级别的实现。

更新逻辑

事务B的update语句，按照一致性读，结果不对。对于更新操作，不能用一致性读规则，（会丢失数据）更新操作的规则是：更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”。

查询逻辑是一致性读，更新逻辑式当前读。

除了update语句外，select语句如果加锁，也是当前读。所以，如果把事务A的查询语句select * from t where id = 1修改一下，加上lock in share mode或for update，此时返回k的值是3.下面这两个select语句，就是分别加了读锁（S锁，共享锁）和写锁（X锁，排他锁）。

mysql> select k from t where id = 1 lock in share mode;
mysql> select k from t where id = 1 for update;

再往前一步，假设事务C不是马上提交的，而是变成了下面的事务C‘，会怎么样：

这是偶，根据“两阶段锁协议”，事务C’没提交，也就是说（1，2）这个版本上的写锁还没释放。而事务B是当前读，必须要读最新版本，而且必须加锁，因此就被锁住了，必须等到 事务C‘释放这个锁，才能继续它的 当前读。

可重复读的核心就是一致性读；而事务更新数据的时候，只能用当前读；如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。

读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：

• 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图。
• 在读提交隔离级别下，每一个语句执行前都会重新计算一个新的视图。

在RC级别下，事务A查询到的k是2，事务B查询到的值是3.

快照在MVCC里是怎么工作的

在可重复读隔离级别下，事务在启动的时候就“拍了个快照”，这个快照是基于整库的。“拍快照”是基于MVCC实现的，数据库中的一行数据，可能会有多个版本（row），每个版本有自己的row trx_id。对于RR，一个事务在启动后，如果一个数据版本是在事务启动之前生成的，就认；如果数据版本是在事务启动之后生成的，事务就不认这个数据版本，要找到它的上一个数据版本，这就是RR的实现。InnoDB利用“所有数据都有多个版本”的这个特性，实现了“秒级创建快照”的能力。