2. 程式人生 > >RC與RR隔離級別下MySQL不同的加鎖解鎖方式

RC與RR隔離級別下MySQL不同的加鎖解鎖方式

阿新 • • 發佈：2018-11-19
RC與RR隔離級別下MySQL不同的加鎖解鎖方式
RC隔離級別
RR隔離級別
半一致讀semi-consistent read
半一致讀發生條件
innodb_locks_unsafe_for_binlog
一開始的例子
RC隔離級別
session 1
session 2
RR隔離級別
session 1
session 2
引申：RR隔離級別，且開啟innodb_locks_unsafe_for_binlog=ON
參考

RC與RR隔離級別下MySQL不同的加鎖解鎖方式

  • MySQL5.7.21
  • 資料準備
  
root@localhost : pxs 05:26:27> show create table dots\G
*************************** 1. row ***************************
      Table
 
: dots
Create Table: CREATE TABLE `dots` (
  `id` int(11) NOT NULL,
  `color` varchar(20) COLLATE utf8_bin NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE
 
=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin
1 row in set (0.00 sec)
​
root@localhost : pxs 05:27:34> select * from dots;
+----+-------+
| id | color |
+----+-------+
|  1 | black |
|  2 | white |
|  3 | black |
|  4 | white |
+----+-------+
4 rows in set (0.00 sec)
​
root@localhost : pxs 01:57:02> show variables like 'innodb_locks_unsafe_for_binlog';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_locks_unsafe_for_binlog | OFF  |
+--------------------------------+-------+
1 row in set (0.00 sec)

RC隔離級別

  • 確認隔離級別
  
root@localhost : pxs 05:27:35> show variables like '%iso%';
+-----------------------+----------------+
| Variable_name        | Value          |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
| tx_isolation          | READ-COMMITTED |
+-----------------------+----------------+
2 rows in set (0.01 sec)
  • 同時開啟兩個會話，按下圖的流程開始操作。

Session 1

Session 2

begin

begin

update dots set color = 'black' where color = 'white';

Query OK, 2 rows affected (0.00 sec)

Rows matched: 2  Changed: 2  Warnings: 0

將color是white的記錄更新為black

 

 

select lock_id,lock_trx_id,lock_mode,lock_type,lock_table,lock_index from information_schema.innodb_locks;

Empty set, 1 warning (0.00 sec)

檢視是否存在鎖衝突

 

 

update dots set color = 'white' where color = 'black';

Query OK, 2 rows affected (0.00 sec)

Rows matched: 2  Changed: 2  Warnings: 0

在另一個會話將color是black的記錄更新為white

select lock_id,lock_trx_id,lock_mode,lock_type,lock_table,lock_index from information_schema.innodb_locks;

Empty set, 1 warning (0.00 sec)

此時再檢視，也不存在鎖衝突

 

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | black |

|  2 | black |

|  3 | black |

|  4 | black |

+----+-------+

4 rows in set (0.00 sec)

session 1查看錶資料發現color列被更新為black

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | white |

|  3 | white |

|  4 | white |

+----+-------+

4 rows in set (0.01 sec)

session 2查看錶資料發現color列被更新為white

commit;

session 1先提交

 

 

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | black |

|  3 | white |

|  4 | black |

+----+-------+

4 rows in set (0.00 sec)

session 2能看到session 1提交後的變更情況

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | black |

|  2 | black |

|  3 | black |

|  4 | black |

+----+-------+

4 rows in set (0.00 sec)

 

 

commit

session 2提交

 

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | black |

|  3 | white |

|  4 | black |

+----+-------+

4 rows in set (0.00 sec)

RR隔離級別

  • 確認隔離級別
  
root@localhost : pxs 05:24:41> show variables like '%iso%';
+-----------------------+-----------------+
| Variable_name        | Value          |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
| tx_isolation          | REPEATABLE-READ |
+-----------------------+-----------------+
2 rows in set (0.01 sec)
  • 同時開啟兩個會話，按下圖的流程開始操作。

Session 1

Session 2

begin

 

 

begin

update dots set color = 'black' where color = 'white';

Query OK, 2 rows affected (0.00 sec)

Rows matched: 2  Changed: 2  Warnings: 0

將color是white的記錄更新為black

 

select lock_id,lock_trx_id,lock_mode,lock_type,lock_table,lock_index from information_schema.innodb_locks;

Empty set, 1 warning (0.00 sec)

檢視是否存在鎖衝突 

 

 

[email protected] : pxs 11:31:13> update dots set color = 'white' where color = 'black';

更新被阻塞

select lock_id,lock_trx_id,lock_mode,lock_type,lock_table,lock_index from information_schema.innodb_locks;

+-------------+-------------+-----------+-----------+--------------+------------+

| lock_id     | lock_trx_id | lock_mode | lock_type | lock_table   | lock_index |

+-------------+-------------+-----------+-----------+--------------+------------+

| 2925:29:3:2 | 2925        | X         | RECORD    | `pxs`.`dots` | PRIMARY    |

| 2924:29:3:2 | 2924        | X         | RECORD    | `pxs`.`dots` | PRIMARY    |

+-------------+-------------+-----------+-----------+--------------+------------+

2 rows in set, 1 warning (0.00 sec)

此時再檢視，確實存在鎖衝突

 

[email protected] : pxs 11:34:06> select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | black |

|  2 | black |

|  3 | black |

|  4 | black |

+----+-------+

4 rows in set (0.00 sec)

session 1查看錶資料發現color列被更新為black

 

commit

session 1先提交

 

 

等session 1提交後，session 2才update成功

 

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | white |

|  3 | white |

|  4 | white |

+----+-------+

4 rows in set (0.00 sec)

檢視update成功後的資料情況

 

commit

session 2提交

 select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | white |

|  3 | white |

|  4 | white |

+----+-------+

4 rows in set (0.00 sec)

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | white |

|  3 | white |

|  4 | white |

+----+-------+

4 rows in set (0.00 sec)

半一致讀semi-consistent read

半一致讀發生條件

  • RC隔離級別
  • RR隔離級別，且innodb_locks_unsafe_for_binlog=true

innodb_locks_unsafe_for_binlog

  • innodb_locks_unsafe_for_binlog預設為off。
     
  • 如果設定為1，會禁用gap鎖，但對於外來鍵衝突檢測（foreign-key constraint checking）或者重複鍵檢測（duplicate-key checking）還是會用到gap鎖。
     
  • 啟用innodb_locks_unsafe_for_binlog產生的影響等同於將隔離級別設定為RC，不同之處是：
    • innodb_locks_unsafe_for_binlog是全域性引數，影響所有session；但隔離級別可以是全域性也可以是會話級別。
    • innodb_locks_unsafe_for_binlog只能在資料庫啟動的時候設定；但隔離級別可以隨時更改。
       
      基於上述原因，RC相比於innodb_locks_unsafe_for_binlog會更好更靈活。

 
啟用innodb_locks_unsafe_for_binlog還有以下作用：

  • For UPDATE or DELETE statements, InnoDB holds locks only for rows that it updates or deletes. Record locks for nonmatching rows are released after MySQL has evaluated the WHERE condition. This greatly reduces the probability of deadlocks, but they can still happen.
    對於update或者delete語句，InnoDB只會持有匹配條件的記錄的鎖。在MySQL Server過濾where條件，發現不滿足後，會把不滿足條件的記錄釋放鎖。這可以大幅降低死鎖發生的概率。
     
  • For UPDATE statements, if a row is already locked, InnoDB performs a “semi-consistent” read, returning the latest committed version to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE. If the row matches (must be updated), MySQL reads the row again and this time InnoDB either locks it or waits for a lock on it.
    簡單來說，semi-consistent read是read committed與consistent read兩者的結合。一個update語句，如果讀到一行已經加鎖的記錄，此時InnoDB返回記錄最近提交的版本，由MySQL上層判斷此版本是否滿足update的where條件。若滿足(需要更新)，則MySQL會重新發起一次讀操作，此時會讀取行的最新版本(並加鎖)。

 
Consider the following example, beginning with this table:
來看下面這個例子

  
CREATE TABLE t (a INT NOT NULL, b INT) ENGINE = InnoDB; 
INSERT INTO t VALUES (1,2),(2,3),(3,2),(4,3),(5,2); 
COMMIT;

In this case, table has no indexes, so searches and index scans use the hidden clustered index for record locking (see Section 14.11.2.1, “Clustered and Secondary Indexes”).
這個例子中，表上沒有索引，所以對於記錄鎖會用到隱藏主鍵。

 
Suppose that one client performs an UPDATE using these statements:
假設某個client開啟了一個update

  
SET autocommit = 0; 
UPDATE t SET b = 5 WHERE b = 3;

Suppose also that a second client performs an UPDATE by executing these statements following those of the first client:
假設另一個client緊接著也開啟一個update

  
SET autocommit = 0; 
UPDATE t SET b = 4 WHERE b = 2;

As InnoDB executes each UPDATE, it first acquires an exclusive lock for each row, and then determines whether to modify it. If InnoDB does not modify the row and innodb_locks_unsafe_for_binlog is enabled, it releases the lock. Otherwise, InnoDB retains the lock until the end of the transaction. This affects transaction processing as follows.
每當InnoDB發起update，會先對每一行記錄加上排它鎖，然後再決定記錄是否滿足條件。如果不匹配，且innodb_locks_unsafe_for_binlog開啟，InnoDB就會把記錄上的鎖釋放掉。否則，InnoDB會一直持有鎖知道事務結束。具體如下：
 
If innodb_locks_unsafe_for_binlog is disabled, the first UPDATE acquires x-locks and does not release any of them:
如果innodb_locks_unsafe_for_binlog沒有開啟，第一個update會一直持有x鎖

  
x-lock(1,2); retain x-lock 
x-lock(2,3); update(2,3) to (2,5); retain x-lock 
x-lock(3,2); retain x-lock 
x-lock(4,3); update(4,3) to (4,5); retain x-lock 
x-lock(5,2); retain x-lock

The second UPDATE blocks as soon as it tries to acquire any locks (because the first update has retained locks on all rows), and does not proceed until the first UPDATE commits or rolls back:
第二個update會阻塞住直到第一個update提交或者回滾

  
x-lock(1,2); block and wait for first UPDATE to commit or roll back

If innodb_locks_unsafe_for_binlog is enabled, the first UPDATE acquires x-locks and releases those for rows that it does not modify:
如果innodb_locks_unsafe_for_binlog開啟，第一個update先持有x鎖，然後會釋放不匹配的記錄上面的x鎖

  
x-lock(1,2); unlock(1,2) 
x-lock(2,3); update(2,3) to (2,5); retain x-lock 
x-lock(3,2); unlock(3,2) 
x-lock(4,3); update(4,3) to (4,5); retain x-lock 
x-lock(5,2); unlock(5,2)

For the second UPDATE, InnoDB does a “semi-consistent” read, returning the latest committed version of each row to MySQL so that MySQL can determine whether the row matches the WHERE condition of the UPDATE:
對於第二個update，InnoDB會開啟半一致讀，此時InnoDB返回記錄最近提交的版本，由MySQL上層判斷此版本是否滿足update的where條件。

  
x-lock(1,2); update(1,2) to (1,4); retain x-lock 
x-lock(2,3); unlock(2,3) 
x-lock(3,2); update(3,2) to (3,4); retain x-lock 
x-lock(4,3); unlock(4,3) 
x-lock(5,2); update(5,2) to (5,4); retain x-lock

一開始的例子

RC隔離級別

session 1

session 1執行update dots set color = 'black' where color = 'white';
由於color列無索引，因此只能走聚簇索引，進行全部掃描。加鎖如下：

注：如果一個條件無法通過索引快速過濾，那麼儲存引擎層面就會將所有記錄加鎖後返回，然後由MySQL Server層進行過濾。因此也就把所有的記錄，都鎖上了。

 
但在實際中，MySQL做了優化，如同前面作用1所提到的。在MySQL Server過濾條件，發現不滿足後，會呼叫unlock_row方法，把不滿足條件的記錄放鎖 (違背了2PL的約束)。這樣做，保證了最後只會持有滿足條件記錄上的鎖，但是每條記錄的加鎖操作還是不能省略的。
實際加鎖如下：

session 2

session 2執行update dots set color = 'white' where color = 'black';
session 2嘗試加鎖的時候，發現行上已經存在鎖，InnoDB會開啟semi-consistent read，返回最新的committed版本(1,black),(2，white),(3,black),(4,white)。MySQL會重新發起一次讀操作，此時會讀取行的最新版本(並加鎖)。如同前面作用2所提到的。
加鎖如下：

MySQL優化後實際加鎖如下：

整個過程現象如前面表格所示。

RR隔離級別

session 1

session 1執行update dots set color = 'black' where color = 'white';
由於color列無索引，因此只能走聚簇索引，進行全部掃描。加鎖如下：

session 2

session 2執行update dots set color = 'white' where color = 'black';更新被阻塞。
等session 1提交commit之後，session 2update才會成功。

引申：RR隔離級別，且開啟innodb_locks_unsafe_for_binlog=ON

  • 環境準備
  
root@localhost : (none) 04:57:46> show  variables like '%iso%';
+-----------------------+-----------------+
| Variable_name        | Value          |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
| tx_isolation          | REPEATABLE-READ |
+-----------------------+-----------------+
2 rows in set (0.01 sec)
​
root@localhost : (none) 04:55:25> show variables like 'innodb_locks_unsafe_for_binlog';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| innodb_locks_unsafe_for_binlog | ON    |
+--------------------------------+-------+
1 row in set (0.00 sec)
​
root@localhost : pxs 05:00:54> select * from dots;
+----+-------+
| id | color |
+----+-------+
|  1 | black |
|  2 | white |
|  3 | black |
|  4 | white |
+----+-------+
4 rows in set (0.00 sec)
  • 開始操作

Session 1

Session 2

begin

 

 

begin

update dots set color = 'black' where color = 'white';                Query OK, 2 rows affected (0.00 sec)

Rows matched: 2  Changed: 2  Warnings: 0

 

select lock_id,lock_trx_id,lock_mode,lock_type,lock_table,lock_index from information_schema.innodb_locks;

Empty set, 1 warning (0.00 sec)

 

 

update dots set color = 'white' where color = 'black';

Query OK, 2 rows affected (0.00 sec)

Rows matched: 2  Changed: 2  Warnings: 0

select lock_id,lock_trx_id,lock_mode,lock_type,lock_table,lock_index from information_schema.innodb_locks;

Empty set, 1 warning (0.00 sec)

 

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | black |

|  2 | black |

|  3 | black |

|  4 | black |

+----+-------+

4 rows in set (0.00 sec)

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | white |

|  3 | white |

|  4 | white |

+----+-------+

4 rows in set (0.00 sec)

commit

 

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | black |

|  2 | black |

|  3 | black |

|  4 | black |

+----+-------+

4 rows in set (0.00 sec)

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | white |

|  3 | white |

|  4 | white |

+----+-------+

4 rows in set (0.00 sec)

 

commit

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | black |

|  3 | white |

|  4 | black |

+----+-------+

4 rows in set (0.00 sec)

select * from dots;

+----+-------+

| id | color |

+----+-------+

|  1 | white |

|  2 | black |

|  3 | white |

|  4 | black |

+----+-------+

4 rows in set (0.00 sec)
  • 注：過程現象滿足RR隔離級別，也符合設定innodb_locks_unsafe_for_binlog=ON的情況。因為前面所講的啟用innodb_locks_unsafe_for_binlog會產生作用1與作用2，所以整個加鎖與解鎖情況與RC隔離級別類似。

參考

《資料庫事務處理的藝術：事務管理與併發控制》
https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_locks_unsafe_for_binlog
http://hedengcheng.com/?p=771
http://hedengcheng.com/?p=220


相關推薦

RC與RR隔離級別下MySQL不同的加鎖解鎖方式

RC與RR隔離級別下MySQL不同的加鎖解鎖方式 RC隔離級別 RR隔離級別 半一致讀semi-consistent read 半一致讀發生條件 innodb_locks_unsafe_for_binlog 一開始的例子 R

InnoDB RR隔離級別下INSERT SELECT兩種死鎖案例剖析

作者：高鵬（重慶八怪） 校稿：葉師傅（部分內容有微調） 原文：http://blog.itpub.net/7728585/viewspace-2146183/ 有網友遇到了在RR隔離級別下insert A select B where B.COL=** 發生死鎖的問題。分析死鎖日誌後，筆者模擬重現了2

MySQL學習總結-演示不同隔離級別下的並發問題

-- val 事務提交 賬戶 演示 zab serializa table into 演示不同隔離級別下的並發問題 1.當把事務的隔離級別設置為read uncommitted，會引發臟讀、不可重復讀和虛讀A窗口set transaction isolation level

記一個mysql環境RR隔離級別轉換成RC的問題

mysql 事務隔離級別 RR RC先了解RR(REPEATABLE-READ)和RC(READ-COMMITTED)的區別.RR隔離級別增加了間隙鎖,避免了幻讀,並且阻止了不可重復讀,讓同一個事務裏面的查詢和修改都是一致的.mysql默認的隔離級別就是RR.雖然說RC隔離級別在同一個事務內會存在查詢出不同數

在RR或RC隔離級別下的使用鎖實現不可重複讀

使用鎖時是當前讀(可以讀取事務提交的資料), 不使用鎖是快照讀mysql> select * from item;+-----+------+----------+| id  | name | order_id |+-----+------+----------+| 

MySQL--REPEATABLE-READ隔離級別下讀取到的“重復數據”

屬於 兩個 客戶端 並發控制 存在 讀取 select 執行 create 在MySQL中，使用MVCC來實現REPEATABLE-READ隔離級別，由於SELECT操作不會對數據加鎖，其他回話可以修改當前回話所讀取過的數據而不會被阻塞，因此讀寫不沖突。 在MVCC並發控

mysql 開發進階篇系列 12 鎖問題(隔離級別下鎖的差異)

padding 排它 改變 level order 並發 aci delete 恢復 1. innodb在不同隔離級別下的一致性讀及鎖的差異 　　不同的隔離級別下，innodb處理sql 時采用的一致性讀策略和需要的鎖是不同的，同時，數據恢復和復制機制的特點，也對一些sql

資料庫【三種讀現象】與【四種隔離級別】+MySQL相關命令

資料庫事務特性ACID 資料庫事務特徵，即 ACID： A Atomicity 原子性 事務是一個原子性質的操作單元，事務裡面的對資料庫的操作要麼都執行，要麼都不執行， C Consistent 一致性 在事務開始之前和完成之後，資料都必須保持一致狀態，必須保證資料庫的完整性

MySQL鎖與事務隔離級別

一、概述 1.1 定義 鎖是計算機協調多個程序或執行緒併發訪問某一資源的機制 計算資源（如CPU、RAM、I/O等）的爭用以外，資料也是一種供需要使用者共享的資源。如何保證資料併發訪問的一致性、有效性是所有資料庫必須解決的一個問題，鎖衝突也是影響資料庫併發訪

演示資料庫不同隔離級別下的事務併發問題

演示不同隔離級別下的併發問題 1.當把事務的隔離級別設定為read uncommitted時，會引發髒讀、不可重複讀和虛讀 A視窗 set transaction isolation level  read uncommitted; start transaction; sele

Spring事務管理與資料庫隔離級別的關係（Spring+mysql）

√: 可能出現    ×: 不會出現 髒讀 不可重複讀 幻讀 Read uncommitted √ √ √ Read committed × √ √ Repeatable read × × √ Serializable × × × 注意：我們討論隔離級別的場景，主要

面試必問的MySQL鎖與事務隔離級別

之前多篇文章從mysql的底層結構分析、sql語句的分析器以及sql從優化底層分析， 還有工作中常用的sql優化小知識點。面試各大網際網路公司必問的mysql鎖和事務隔離級別，這篇文章給你打神助攻，一飛沖天。 鎖定義 鎖是計算機協調多個程序或執行緒併發訪問某一資源的機制。 在資料庫中，除了傳統的計算資源（

淺析SQL Server在可序列化隔離級別下，防止幻讀的範圍鎖的鎖定問題

tran .html 表格 des locks 構建 isolation 錯誤 ron 本文出處：http://www.cnblogs.com/wy123/p/7501261.html （保留出處並非什麽原創作品權利，本人拙作還遠遠達不到，僅僅是為了鏈接到原文，因為後

事務的隔離級別和mysql事務隔離級別修改

eat log control 容易 新的 pda mit 全局 nbsp A事務做了操作 沒有提交 對B事務來說 就等於沒做 獲取的都是之前的數據 但是 在A事務中查詢的話 查到的都是操作之後的數據 沒有提交的數據只有自己看得到，並沒有update到數據庫。 查看In

Sql Server中的事務與事務隔離級別

事務是資料庫進行併發控制非常重要的機制。 1、什麼是事務？ 　　事務是作為單個邏輯工作單元執行的一系列操作，它由一條或者一組語句組成，它們麼全部成功，要麼全部失敗。 　　舉個例子，比如在12306訂火車票，要麼你訂票成功，餘票顯示就減少一張；要麼你訂票失敗，餘票顯示還是那麼多。不允許出現

資料庫事務的特性與事務隔離級別

                             資料庫事務的特性與隔離級別 事務     事務簡單的理解就是要在

資料庫事務四大特性及事務隔離級別在mysql中的具體體現

事務的四大特性 原子性 指事務是一個不可分割的工作單位，事務中的操作要麼都發生，要麼都不發生。 一致性 指事務必須使資料庫從一個一致性狀態轉換到另一個一致性狀態。拿轉賬來說，不管如何轉賬，錢的總數不變。 隔離性 指多個使用者訪問資料庫時，使用者為每個資

MySQL使用可重複讀作為預設隔離級別的原因（二)-》Innodb鎖機制：Next-Key Lock 淺談

資料庫使用鎖是為了支援更好的併發，提供資料的完整性和一致性。InnoDB是一個支援行鎖的儲存引擎，鎖的型別有：共享鎖（S）、排他鎖（X）、意向共享（IS）、意向排他（IX）。為了提供更好的併發，InnoDB提供了非鎖定讀：不需要等待訪問行上的鎖釋放，讀取行的一個快照。該方法是通過InnoDB的一個特

hibernate第三天——session的快取與事務隔離級別，一對一關係，多種方式查詢

package cn.itcast.k_query_hql; import java.util.Arrays; import java.util.List; import org.hibernate.Query; import org.hibernate.Session; import org.hiber

SQL Server 中的事務與事務隔離級別以及如何理解髒讀, 未提交讀,不可重複讀和幻讀產生的過程和原因

原本打算寫有關 SSIS Package 中的事務控制過程的，但是發現很多基本的概念還是需要有 SQL Server 事務和事務的隔離級別做基礎鋪墊。所以花了點時間，把 SQL Server 資料庫中的事務概念，ACID 原則，事務中常見的問題，問題造成的原因和事務隔離級別等這些方面的知識好好的整理了一下。