差点掉坑，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结果SessionB1beginselect * from test_innodb_read where id=11 2 update test_innodb_read set value = 2 where id=13select * from test_innodb_read where id=11 4select * from test_innodb_read where id=1 lock in share mode2 由于设置了自动提交，所以SessionB的更新语句执行完就已经提交了，从结果可以看到普通的Select不受其他事务影响，所以读到的数据都是同一版本，而在加锁读的情况下采取的是读最新的数据，所以读到的数据是最新提交的数据。DML 操作在进行数据变更操作的时候，也会拿到最新的数据，用的还是上面的表，插入一条测试数据insert into test_innodb_read values (2, 1);然后开启两个 Session，分别执行以下操作，时间点SessionA结果SessionB1beginselect * from test_innodb_read where id=21 2 update test_innodb_read set value = 2 where id=23select * from test_innodb_read where id=21 4update test_innodb_read set value=value+1 where id=2 5select * from test_innodb_read where id=23 SessionA在时间点 5 查看数据拿到的是 3 而不是 2，原因是，事务在对数据进行更新操作时(时间点4)，会先读取一次数据，这次读取的不是事务开始版本，而是数据的最新提交的值 2。如果不读取最新数据的话，就等于覆盖了SessionB的更新，所以读到的是 2，最后得到的数据是 3。最后当我知道这个知识点后，感觉背后一凉，以前写代码的时候，喜欢在事务里先把数据查出来，内存中相加减，再存库，现在想想这样做就是BUG啊，坑…不得不说，极客时间上面的这个MySQL课程还是很值的，至少让我推翻了以前的想法MySQL实战45讲-8 事务到底是隔离的还是不隔离的