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 '',

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

  `version` mediumint(8) NOT NULL DEFAULT '',

  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 的方式来做并发控制是可行的.

巴特西

MySQL 的乐观并发控制Optimistic concurrency control

最新文章

热门文章