MySQL單表模擬鎖的有哪些場景

這篇文章主要介紹MySQL單表模擬鎖的有哪些場景，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

  在MySQL中對于并發，鎖問題總是會有很多值得討論的地方，但是通常來說，要模擬這些鎖或者一些鎖的問題需要花點功夫，比如創建多個表，創建大量的數據，然后像調試鐘表的秒針一樣，讓問題剛好復現在哪個時間點上。如果換一個角度，單表來模擬這類而是可以嗎，其實是可行的。

   今天簡單通過單表的測試模擬死鎖，事務中的隱式提交（其實可以理解是個bug),間隙鎖。

初始化數據

首先的準備工作就是初始化數據，我們創建一個表test,事務隔離級別為默認的RR。

建表語句：

create table test(

id int not null ,

name int ,

primary key(id),

unique key(name)

) engine=innodb;

事務隔離級別：

mysql> show variables like '%isolation%';

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

| Variable_name | Value           |

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

| tx_isolation  | REPEATABLE-READ |

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

1 row in set (0.00 sec)

除此之外就是打開兩個窗口，我們簡稱為會話1，會話2.

模擬死鎖

我們開始先模擬一下死鎖問題。

會話1：

我們開啟一個事務，插入一行記錄，數據就選做今天的日期吧。

mysql>begin；

mysql> insert into test values(2017,827);

Query OK, 1 row affected (0.01 sec)

會話2；

mysql> insert into test values(2016,827);

這個時候會話2會阻塞，這個時候有一種特殊的情況，那就是阻塞超時，如果超時，會自動停止。

會話1：

mysql> insert into test values(2018,826);

Query OK, 1 row affected (0.00 sec)

可見會話1中的DML操作依舊是可以的。

會話2：

mysql> insert into test values(2016,827);

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

如果看會話2的情況，就會發現產生了死鎖。

如果要嘗試事務隔離級別RC,其實表現的效果是一樣的。

仔細看看這個操作的過程就會發現，還是蠻“奇怪”的，數據之間彼此沒有直接的依賴關聯，怎么會產生死鎖，這個里面有銀式鎖升級，還有間隙鎖的一些東西，留給大家思考吧。

模擬意料之外的事務自動提交

為了基于上面的測試數據，讓兩條數據成功插入，我們在會話2中結束事務。

mysql>commit;

然后開始做意料之外的事務自動提交測試，這一次我們在同一個會話中測試即可。問題的背景是如果我們顯式聲明事務，在同一會話中做了DML操作，沒有提交，如果再開啟一個事務，之前的事務會自動提交。

會話1：

這是基于場景1的測試之后的數據情況。

mysql> select *from test;

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

| id   | name |

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

| 2018 |  826 |

| 2017 |  827 |

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

2 rows in set (0.00 sec)

我們顯式聲明一個事務。

mysql> begin;

Query OK, 0 rows affected (0.02 sec)

然后插入一條記錄，重新給一個日期。

mysql> insert into test values(2019,825);

Query OK, 1 row affected (0.00 sec)

這個時候沒有提交，我們在當前會話中重新再開啟一個事務。

mysql > begin;

mysql > insert into test values(2015,830);

這個時候如果在會話2中查看，其實會發現，事務已經幫你提交了。

mysql> select *from test;

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

| id   | name |

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

| 2018 |  826 |

| 2017 |  827 |

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

2 rows in set (0.00 sec)

在會話1我們繼續回滾事務，會發現于事無補。

mysql> rollback;

Query OK, 0 rows affected (0.01 sec)

這個時候數據已經自動提交了一部分。

mysql> select *from test;

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

| id   | name |

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

| 2018 |  826 |

| 2017 |  827 |

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

2 rows in set (0.00 sec)

間隙鎖測試

上面的測試場景其實還是多多少少都有些關聯，其中第一個場景和間隙鎖也有關系，我就簡單用單表模擬一下間隙鎖。

首先還是保證事務隔離級別是RR,因為間隙鎖是RR隔離級別特供，RC中就沒有間隙鎖這樣的定制，在并發場景中還是有不小的影響。我們來看看效果。

會話1：

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

指定數據范圍，然后顯示聲明。

mysql> select id from test where id <2019 lock in share mode;

+------+

| id   |

+------+

| 2018 |

| 2017 |

+------+

2 rows in set (0.00 sec)

會話2：

會話2中也開啟一個事務，插入一條記錄。結果就被阻塞了。

mysql> begin;

Query OK, 0 rows affected (0.00 sec)

mysql> insert into test values(2016,829);

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

直到事務超時才作罷。

以上是“MySQL單表模擬鎖的有哪些場景”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！