ef mysql 乐观并发_MySQL 的乐观并发控制Optimistic concurrency control

默认情况下, MySQL的Innodb事务隔离级别是重复读 repeatable read,

SELECT @@GLOBAL.tx_isolation, @@tx_isolation;

REPEATABLE-READ    REPEATABLE-READ

进行以下测试, 同时开两个session, S1 和 S2, 都将autocommit关掉

set autocommit=0;

测试使用的是一张简单的表, 只有一行数据

CREATE TABLE`t1` (

`v1`tinyint(2) NOT NULL DEFAULT '0',

`v2`tinyint(2) NOT NULL DEFAULT '0',

`version` mediumint(8) NOT NULL DEFAULT '0',PRIMARY KEY(`v1`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

row:1 1 0

01 - S1 执行 select * from t1; 看到1, 1, 0

02 - S2 执行 select * from t1; 看到1, 1, 0

03 - S2 执行 update t1 set v2=2, version=version+1 where v1=1 and version=0; (Affected rows: 1)

04 - S2 执行 select * from t1; 看到1, 2, 1

05 - S1 执行 select * from t1; 看到1, 1, 0 - 无变化

06 - S1 执行 update t1 set v2=2, version=version+1 where v1=1 and version=0; 被挂起, 一直等待

07 - S2 执行 commit;  第06步的S1查询结束, 显示(Affected rows: 0)

08 - S1 执行 select * from t1; 依然看到1, 1, 0

09 - S1 执行 commit;

10 - S1 执行 select * from t1; 看到1, 2, 1 - 这时候数据才更新

由此可以验证, 在 REPEATABLE-READ 的隔离级别下, 一个事务并不能觉察到事务外部的数据变化, 所有读取的数据自事务开始后就不变, 但是update类型的操作, 会受到事务外部数据变化的影响, 首先是如果同一行数据有外部事务未提交, 则当前操作需要排队, 其次是如果同一行数据已经被外界更改, 则update操作会受影响, 例如本例中 Affected rows: 0

由此可见, 通过形如 update t1 set v2=2, version=version+1 where v1=1 and version=0 的方式来做并发控制是可行的.