事务隔离机制原理分析以及是否可以防止订单超卖

事务的隔离机制是指&＃xff1a;

Read Uncommitted&＃xff08;读取未提交内容&＃xff09;
Read Committed&＃xff08;读取提交内容&＃xff09;
Repeatable Read&＃xff08;可重读&＃xff09;
Serializable&＃xff08;可串行化&＃xff09;

具体的解释最经典的MySQL书《高性能MySQL(第3版)》已经有了就不在其他地方再引用了&＃xff1a;

隔离机制的比较

其实也有人喜欢用锁来控制并发&＃xff0c;书中还提到了“隐式”和“显示锁定”&＃xff0c;是这么建议的&＃xff1a;

虽然这样&＃xff0c;但是其实如果不经过实际的演练还是很难理解上面说的事务隔离机制到底怎么样可以防止并发。

1.查看MySQL版本

我们的版本是5.1.7

2.查看存储引擎

>show engines;

存储引擎是&＃xff1a;InnoDB

3.实验表

假设有个商品表g&＃xff0c;关键字段num表示库存&＃xff0c;name表示商品名称

主要就是看不同事务隔离机制下并发修改库存是否会出现超卖。

假设我们的程序需要先查询库存&＃xff0c;如果库存>0都可以卖&＃xff0c;update扣库存&＃xff0c;否则rollback。

为了制造并发肯定需要2个事务&＃xff0c;假设是A和B。

4.确认事务隔离机制

修改会话的事务隔离级别

set session transaction isolation level read uncommitted;
set session transaction isolation level read committed;
set session transaction isolation level repeatable read;
set session transaction isolation level serializable;

>select &＃64;&＃64;global.tx_isolation,&＃64;&＃64;tx_isolation;

5.Serializable

场景一&＃xff1a;

显然一开始AB查询的数据是一样的num&＃61;1

A开始update

这时候在等待&＃xff0c;无法update。

过一会就超时了。

如果这个时候B也update那么一样会等待超时

所以这样&＃xff0c;AB就会都超时。

这时即使commit也是返回0&＃xff0c;数据库不会变化。

场景二&＃xff1a;

A在update等待的时候&＃xff0c;B马上commit&＃xff0c;但是B没有update

查看结果

这次A成功的扣库存。

所以从上面可以得出一个结论&＃xff1a;serializable是可以很好的控制并发。

然后需要把库存改为1&＃xff0c;便于测试。

6.read committed

>set session transaction isolation level read committed;

>select &＃64;&＃64;global.tx_isolation,&＃64;&＃64;tx_isolation;

场景三&＃xff1a;

初始化AB查出来的库存都是1&＃xff0c;然后A可以update一条数据&＃xff0c;无等待。

这时候AB再比较下库存&＃xff0c;A已经是0&＃xff0c;B是1&＃xff0c;因为A没有commit。

然后A执行commit操作&＃xff0c;这时候B再查已经是库存0&＃xff1b;

这时候B执行update返回是0行&＃xff0c;因为update不能满足where条件&＃xff0c;所以B只有Commit&＃xff0c;然后重新提交。

场景四&＃xff1a;

一开始AB都是一样的库存1&＃xff0c;然后A开始update&＃xff0c;然后A的库存是0&＃xff0c;B是1&＃xff0c;因为A还没有提交。

这时候B再update

按照前面的经验&＃xff0c;B等待其实是再等A提交&＃xff0c;A如果一直不提交&＃xff0c;B就会超时。

这时A提交commit&＃xff0c;B查询就得到A更新后的结果&＃xff0c;这时B查到库存是0自然不会去更新&＃xff0c;也就只能结束事务。

场景五&＃xff1a;

AB先后update&＃xff0c;然后A在B超时之前commit&＃xff0c;这时由于B已经读到A更新后的结果0&＃xff0c;所以B就不能成功update。

7.repeatable read

>set session transaction isolation level repeatable read;

>select &＃64;&＃64;global.tx_isolation,&＃64;&＃64;tx_isolation;

场景六&＃xff1a;

然后A开始update&＃xff0c;然后A和B分别读到库存是1和0

然后A提交commit&＃xff0c;这时候再查看A和B的库存还是保持不变。

这时候B再次尝试update

依然是返回0条&＃xff0c;说明更新不成功。

场景八&＃xff1a;

AB同时update

如果A不及时commit那么B肯定会超时

场景九&＃xff1a;

就是场景八A及时commit

如果A及时commit

所以可以看出无论是read committed还是repeatable read只要update的条件where  num>0足够充分都是可以控制并发防止超卖的。

如果没有带where  num>0这个控制条件&＃xff0c;那么肯定会可以update成功的。

8.read uncommitted

这个是需要杜绝的&＃xff0c;就不讨论了。

9.如果没有带where  num>0&＃xff0c;那么会怎么样呢。其实只要理解了上述流程就可以想明白会怎么样。

对于read committed

A已经update&＃xff0c;B读到库存是0自然不会去更新&＃xff1b;

A没有update&＃xff0c;B读到库存是1&＃xff0c;这要看A会不会及时提交&＃xff1b;

如果A及时提交&＃xff0c;B自然会去更新因为满足where条件&＃xff0c;且成功&＃xff0c;这样就超卖-1&＃xff1b;

这时候由于B没有提交&＃xff0c;所以AB分别查出0和-1

然后B提交commit&＃xff0c;AB查出的都是-1&＃xff0c;就不演示了。

修改会话为repeatable read

AB先后update&＃xff0c;B在等待

然后A立即提交commit&＃xff0c;B马上update得到返回。

结果就是-1产生了超卖&＃xff1a;

总结&＃xff1a;

1.使用serializable是可以防止超卖&＃xff0c;但是性能怎么样需要数据说明&＃xff1b;

2.read committed和repeatable read带上where条件库存num>0都是可以防止超卖的&＃xff0c;不过需要处理超时。

3.其他各种组合情况还会更复杂&＃xff0c;具体具体问题具体分析。