差点掉坑，MySQL一致性读原来是有条件的

众所周知，在设定了隔离等级为Repeatable Read及以上时，InnoDB 能够实现数据的一致性读。换句话来讲，就是事务执行的任意时刻，读取到的数据是同一个快照，不会受到其余事务的更新影响。

之前一直觉得在事务内读到的数据不会受其余事务影响，后来发现只有普通的select语句才是一致性读。若是是update, delete, select for update, select in share mode等语句是当前读，读的是数据库最新数据, 下面是两个例子。

加锁读

建立一个测试用的表, 而后插入一条测试用的数据

create table test_innodb_read(
    id int not null primary key,
    value int
) engine = InnoDB charset=utf8;
insert into test_innodb_read values (1, 1);

当前autocommit和隔离等级以下

db83-3306>>select @@autocommit;
+--------------+
| @@autocommit |
+--------------+
|            1 |
+--------------+
1 row in set (0.00 sec)

db83-3306>>select @@transaction_isolation;
+-------------------------+
| @@transaction_isolation |
+-------------------------+
| REPEATABLE-READ         |
+-------------------------+
1 row in set (0.00 sec)

而后开启两个 Session，分别执行如下操做

时间点	SessionA	结果	SessionB
1	begin select * from test_innodb_read where id=1	1
2			update test_innodb_read set value = 2 where id=1
3	select * from test_innodb_read where id=1	1
4	select * from test_innodb_read where id=1 lock in share mode	2

因为设置了自动提交，因此SessionB的更新语句执行完就已经提交了，从结果能够看到普通的Select不受其余事务影响，因此读到的数据都是同一版本，而在加锁读的状况下采起的是读最新的数据，因此读到的数据是最新提交的数据。

DML 操做

在进行数据变动操做的时候，也会拿到最新的数据，用的仍是上面的表，插入一条测试数据

insert into test_innodb_read values (2, 1);

而后开启两个 Session，分别执行如下操做，

时间点	SessionA	结果	SessionB
1	begin select * from test_innodb_read where id=2	1
2			update test_innodb_read set value = 2 where id=2
3	select * from test_innodb_read where id=2	1
4	update test_innodb_read set value=value+1 where id=2
5	select * from test_innodb_read where id=2	3

SessionA在时间点 5 查看数据拿到的是 3 而不是 2，缘由是，事务在对数据进行更新操做时(时间点4)，会先读取一次数据，此次读取的不是事务开始版本，而是数据的最新提交的值 2。若是不读取最新数据的话，就等于覆盖了SessionB的更新，因此读到的是 2，最后获得的数据是 3。

最后

当我知道这个知识点后，感受背后一凉，之前写代码的时候，喜欢在事务里先把数据查出来，内存中相加减，再存库，如今想一想这样作就是BUG啊，坑...

不得不说，极客时间上面的这个MySQL课程仍是很值的，至少让我推翻了之前的想法

MySQL实战45讲-8 事务究竟是隔离的仍是不隔离的