mysql innodb事务隔离级别

read uncommitted(未提交读)

事务可以读取未提交的数据，性能上比其他隔离级别不会好太多，但是缺少了其他事务的好处。

read commited(提交读）

事务只能读取已经提交的数据，但有可能出现不可重复读

repeatable read(可重复读）

保证在同一个事务中，多次读取的记录的结果是一致的，但会出现幻读

serializable(串行化)

每一行的数据都加锁

 

更新丢失

是指并发下两次更新同时进行，后一次更新覆盖了前一次更新的情况,数据库可以进行规避，多出现于应用程序中

脏读

一个事务可以读取其他事务未提交的修改

不可重复读

即同一个事务可能读取到的同一行数据是不一样的

幻读

指的是某个读取的事务期间，其他事务对该事务范围内的记录进行新增删除的操作，此时当前事务会出现多一行或者少一行的情况

隔离级别	更新丢失	脏读	不可重复读	幻读
READ UNCOMMITTED	NO	YES	YES	YES
READ COMMITED	NO	NO	YES	YES
REPEATABLE READ	NO	NO	NO	YES
SERIALIZABLE	NO	NO	NO	NO

下面看一下演示例子，演示前先说明一下用到的sql

查看隔离级别

SELECT @@tx_isolation;

设置隔离级别

SET SESSION TRANSACTION ISOLATION LEVEL 隔离级别

开启事务:

START TRANSACTION

提交事务

COMMIT

回滚事务

ROLLBACK

演示表

CREATE TABLE `account` (
  `id` int(2) NOT NULL AUTO_INCREMENT,
  `name` varchar(10) NOT NULL,
  `money` int(3)  NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

数据准备：

 

更新丢失

需要在程序里面弄，举个例子吧，比如并发情况下，两个用户A，B购买商品，商品只有2个，同时读取都是可以购买的，然后做修改后，最终的到商品库存为1，因为A读取到商品库存为2并减一此时把1更新，而B也读取到库存为2，同样减一，B保存修改，此时结束，商品库存为1，此时A的更新就丢失了

脏读

mysql innodb默认隔离级别为可重复读，现在把他改为最低的级别——未提交读

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

开启两个会话，并且都把他们至为未提交读,开启事务，会话1取钱，会话2查询余额后取钱

此时会话1先取钱

START TRANSACTION
UPDATE account SET money = money - 100 WHERE id = 1

 

然后会话2查询后继续扣钱

START TRANSACTION
SELECT * FROM account WHERE id = 1;

此时查询时的金额

此时会话1回滚

而后会话2对上次读出来的900进行更新（这就出现了脏读的情况）

UPDATE account SET money=900-100 WHERE id = 1;

最后变成了800，会话1已经回滚了，正常应该是900才对

不可重复读

下面把隔离级别再提高一级

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED

重复脏读的步骤，会发现不会出现同一个事务中读取到其他事务未提交的修改的情况。

但是会出现不可重复读，即同一个事务下，对某一行数据读取出来的值有所不同

会话1，会话2开启事务

会话2先查询

SELECT * FROM account WHERE id=1

发现是800

此时会话1再次更新

UPDATE account SET money = money+200 WHERE id = 1;

会话2再次查询，发现值还是800，因为其他事务的未提交修改不会影响该事务（从而印证该隔离级别不会出现脏读的情况），但当会话1提交更新以后，会话2再次查询发现变为1000了，此时就出现不可重复读了，会话1只想对初始查出来的值进行操作，而后发现money却变化了。

幻读：

把隔离级别再次提高，repeatable read

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ

再次重复出现不可重复读的情况，一开始都是1000块

然后会话1读取，确定是1000，发现会话1一直都是那个数字，这也是innodb默认的隔离级别，但是如果在该数据下进行修改，比如会话2已经对其进行取钱200此时剩800（会话2提交事务），会话1再取钱100，然后查询（事务尚未提交），会发现是原来的1000减去100，而不是已经提交的800，此时提交事务，会发现只有700，也就是说不会影响最终结果

而幻读是怎么出现的呢？

由于mysqlinoodb在repeatable read的隔离级别下也可以避免幻读,这里是如何避免的呢，他使用mvcc和行锁+gap锁进行优化，

先了解一下概念

当前读：update,insert,delete ,select lock in share mode/for update

快照读：不加锁的非阻塞读，不加锁，不为串行化

在RR级别下通过伪mvcc(多版本并发控制)实现非阻塞读（快照读）

实现：

避免幻读的表象

DB_TRX_ID:最近一次的修改事务id

DB_ROLL_PTR：回滚指针

DB_ROW_ID：行号，行id

undo日志：对数据操作时，会产生的日志，insert undo（事务回滚）,update undo(事务回滚、当前读需要)，如果事务不需要会被删除

 

read view可见性判断，确定当前事务的版本，与其他事务的活跃版本比较，找到较低的稳定版本并通过db_roll_ptr指针展示

避免幻读内在

next-key锁 （行锁+gap锁）

gap锁：只在RR级别上，间隙锁，作用在索引树中插入新纪录的空隙，锁定一个范围的锁

主键索引、唯一索引：如果where全部命中，只会加记录锁，不会用gap锁，如果对唯一索引上锁，会把主键也一并上锁，防止并发

where条件部分命中或全部命中，会加gap锁

非唯一索引或不走索引：gap锁

由于这些性质，在rr级别下无法看出幻读现象的出现

这时候把事务级别降到最低 read committed 

然后开启事务，会话1为该查询语句上共享读锁，其他事务在修改当前持有的记录要等待该事务提交或回滚才可以操作

SELECT * FROM account  LOCK IN SHARE MODE

会话2插入数据，因为是在会话1范围外，所以可以插入，而三条记录范围内的修改操作均会被阻塞。

INSERT INTO account VALUES(4,"test",100)

会话2提交事务

此时会话1打算对原有的三个进行数据更新，发现更新了4行，出现了幻读情况。

此时把隔离级别改为串行化即可解决，但同时并发性能会下降