MySQL 的樂觀併發控制Optimistic concurrency control

時間 2019-11-11

標籤 mysql 樂觀併發控制 optimistic concurrency control 欄目 MySQL 简体版

原文原文鏈接

默認狀況下, MySQL的Innodb事務隔離級別是重複讀 repeatable read, session

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 - 這時候數據才更新spa

由此能夠驗證, 在 REPEATABLE-READ 的隔離級別下, 一個事務並不能覺察到事務外部的數據變化, 全部讀取的數據自事務開始後就不變, 可是update類型的操做, 會受到事務外部數據變化的影響, 首先是若是同一行數據有外部事務未提交, 則當前操做須要排隊, 其次是若是同一行數據已經被外界更改, 則update操做會受影響, 例如本例中 Affected rows: 0code

因而可知, 經過形如 update t1 set v2=2, version=version+1 where v1=1 and version=0 的方式來作併發控制是可行的.blog