【转】事物隔离级别---未提交读，已提交读，可重复读，可串行读

事务的四种隔离级别

(引自: Innodb中的事务隔离级别和锁的关系)

在数据库操作中，为了有效保证并发读取数据的正确性，提出的事务隔离级别。我们的数据库锁，也是为了构建这些隔离级别存在的。

隔离级别	脏读（Dirty Read）	不可重复读（NonRepeatable Read）	幻读（Phantom Read）
未提交读（Read uncommitted）	可能	可能	可能
已提交读（Read committed）	不可能	可能	可能
可重复读（Repeatable read）	不可能	不可能	可能
可串行化（Serializable ）	不可能	不可能	不可能

未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据

提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)

可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读

串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞

可重复读和幻读

在可重复读中，该sql第一次读取到数据后，就将这些数据加锁（悲观锁），其它事务无法修改这些数据，就可以实现可重复读了。但这种方法却无法锁住insert的数据，所以当事务A先前读取了数据，或者修改了全部数据，事务B还是可以insert数据提交，这时事务A就会发现莫名其妙多了一条之前没有的数据，这就是幻读，不能通过行锁来避免。需要Serializable隔离级别 ，读用读锁，写用写锁，读锁和写锁互斥，这么做可以有效的避免幻读、不可重复读、脏读等问题，但会极大的降低数据库的并发能力。

但是MySQL、ORACLE、PostgreSQL等成熟的数据库，出于性能考虑，都是使用了以乐观锁为理论基础的MVCC（多版本并发控制）来实现。

实际测试结果

对相同db实例创建两个连接：a和b，来测试select, select for update, update语句的生效情况

不使用select for update行级锁

	a先提交	b先提交
a先开启事务	b的update内容	a的update内容
a先开启事务	b的update内容	a的update内容

结果是谁最后提交，谁的结果生效

a先使用select for update, update行级锁

	a使用select for update	a使用select for update	a使用update
a开启事务,b不开启	b里面的select for update和update被阻塞	b不受影响	b里面的select for update和update被阻塞
a不开启事务,b开启	b不受影响	b不受影响	b不受影响
a,b开启事务	b里面的select for update和update被阻塞	b不受影响	b里面的select for update和update被阻塞
a,b不开启事务	b不受影响	b不受影响	b不受影响

结果是只有使用begin显式开启事务时，使用select for update才会对数据加上行级锁，对其他连接的的select for update(对select没有影响)和update造成阻塞效果。

a上锁后修改提交，b读取到的内容

下面是a开启事务，然后使用a使用select for update，接着b使用select for update/select，a执行updat，最后commit，观察整个过程中b的查询效果。

	b使用select for update	b使用select
b开启事务	b里面的select for update被阻塞，a提交后，b读到的是a修改的内容	b不受a阻塞，读到的仍是b事务开启时的内容
b不开启事务	b里面的select for update被阻塞，a提交后，b读到的是a修改的内容	b不受a阻塞，读到的数据在a提交后变化

在连接a使用begin开启事务之后，select for update和update对连接b的阻塞效果

	a先执行select for update	a先执行update
b后执行select	未阻塞	未阻塞
b后执行select for update	阻塞	阻塞
b后执行update	阻塞	阻塞

原文：https://www.cnblogs.com/catmelo/p/8878961.html