【MySQL】MySQL鎖和隔離級别淺析一

參考：

本文隻是對于“SELECT ... LOCK IN SHARE MODE”和“SELECT ...

FORUPDATE”事務中的鎖和RR隔離級别内的測試，針對于表結構、索引結構以及其他隔離級别情況下的觸發鎖類型，可以參考網易何登成網盤中“MySQL

加鎖處理分析.pdf”這篇文章，很細緻。

何登成百度網盤：

下面的内容是參考上面連結博文測試的内容，文字略加修改，友善自己查詢和閱讀。

測試一：

<col>

　

Variable_name

Value

tx_isolation

REPEATABLE-READ

session 1

session 2

1

update未送出

select

update t1 set b=‘z‘

where a=1

select * from t1

session 1 commit之前，普通select傳回的結果都是session 1

commit送出前結果

2

select … lock in share mode

update t1 set b=‘y‘

where a=1 lock in

share mode

session 1 commit以後session 2傳回結果

3

select … for update

update t1 set b=‘x‘

where a=1 for

update

RR的隔離級别，對于a=1行的update操作會給行加排他鎖

1、普通的select隻是對于session

1事務送出前的行資料快照查詢

2、select … lock in share mode屬于共享鎖，與session

1的排他鎖互斥，需要等待session 1送出或者復原

3、select … for update屬于排他鎖，與session

1的排它鎖互斥，是以也需要等待需要等待session 1送出或者復原

測試二：

query

result

begin

select * from t1 where a=1 for update

4

update t1 set b=‘u‘ where a=1

session 2查詢需要等待session 1事務處理完成或者復原

5

select * from t1 where a=1 for

或

select * from t1 where a=1 lock in share mode

無傳回，等待

6

select * from t1 where a=1 for

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

| a | b |

| 1 | u

|

1 row in set (0.00 sec)

session 2查詢需要等待session 1事務處理完成或者復原

7

commit

1 row in set (33.02 sec)

8

update t1 set b=‘w‘ where a=1

session 1事務處理完成或者復原後session 2獲得查詢結果

9

| 1 | w

10

session 2事務處理完成或者復原後session 1獲得查詢結果

11

12

1 row in set (10.46 sec)

測試三：

session

2事務雖然隻有一個select但是由于update和select兩個所持有的共享鎖、排他鎖互斥，是以session

1的update事務需要等到session 2送出以後完成

update t1 set b=‘m‘ where a=1

Query OK, 1 row affected (17.49 sec)

Rows matched: 1  Changed: 1  Warnings: 0

select * from t1 where a=1 lock in share mode

session 1未送出事務，等待

| 1 | m

1 row in set (7.16 sec)

 此後又做了幾個測試，總結如下：

type

類型

快照

select … lock in share mode

共享鎖

select … for update

排它鎖

DML

共享實時

互斥等待