MySQL中InnoDB的間隙鎖問題
在為一個(gè)客戶排除死鎖問題時(shí)我遇到了一個(gè)有趣的包括InnoDB間隙鎖的情形。對(duì)于一個(gè)WHERE子句不匹配任何行的非插入的寫操作中,我預(yù)期事務(wù)應(yīng)該不會(huì)有鎖,但我錯(cuò)了。讓我們看一下這張表及示例UPDATE。
mysql> SHOW CREATE TABLE preferences \G
*************************** 1. row ***************************
Table: preferences
Create Table: CREATE TABLE `preferences` (
`numericId` int(10) unsigned NOT NULL,
`receiveNotifications` tinyint(1) DEFAULT NULL,
PRIMARY KEY (`numericId`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT COUNT(*) FROM preferences;
+----------+
| COUNT(*) |
+----------+
| 0 |
+----------+
1 row in set (0.01 sec)
mysql> UPDATE preferences SET receiveNotifications='1' WHERE numericId = '2';
Query OK, 0 rows affected (0.01 sec)
Rows matched: 0 Changed: 0 Warnings: 0
---TRANSACTION 4A18101, ACTIVE 12 sec 2 lock struct(s), heap size 376, 1 row lock(s) MySQL thread id 3, OS thread handle 0x7ff2200cd700, query id 35 localhost msandbox Trx read view will not see trx with id >= 4A18102, sees < 4A18102 TABLE LOCK table `test`.`preferences` trx id 4A18101 lock mode IX RECORD LOCKS space id 31766 page no 3 n bits 72 index `PRIMARY` of table `test`.`preferences` trx id 4A18101 lock_mode X
這是為什么呢,Heikki在其bug報(bào)告中做了解釋,這很有意義,我知道修復(fù)起來很困難,但略帶厭惡地我又希望它能被差異化處理。為完成這篇文章,讓我證明下上面說到的死鎖情況,下面中mysql1是第一個(gè)會(huì)話,mysql2是另一個(gè),查詢的順序如下:
mysql1> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql1> UPDATE preferences SET receiveNotifications='1' WHERE numericId = '1';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0
mysql2> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql2> UPDATE preferences SET receiveNotifications='1' WHERE numericId = '2';
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0 Changed: 0 Warnings: 0
mysql1> INSERT INTO preferences (numericId, receiveNotifications) VALUES ('1', '1'); -- This one goes into LOCK WAIT
mysql2> INSERT INTO preferences (numericId, receiveNotifications) VALUES ('2', '1');
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
現(xiàn)在你看到導(dǎo)致死鎖是多么的容易,因此一定要避免這種情況——如果來自于事務(wù)的INSERT部分導(dǎo)致非插入的寫操作可能不匹配任何行的話,不要這樣做,使用REPLACE INTO或使用READ-COMMITTED事務(wù)隔離。
相關(guān)文章
MySQL聯(lián)合查詢之輕松實(shí)現(xiàn)數(shù)據(jù)關(guān)聯(lián)詳解
MySQL中當(dāng)查詢數(shù)據(jù)來自多張表時(shí)需要用到關(guān)聯(lián)查詢,下面這篇文章主要給大家介紹了關(guān)于MySQL聯(lián)合查詢之輕松實(shí)現(xiàn)數(shù)據(jù)關(guān)聯(lián)的相關(guān)資料,文中通過實(shí)例代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-06-06
MySQL出現(xiàn)SQL Error (2013)連接錯(cuò)誤的解決方法
這篇文章主要介紹了MySQL出現(xiàn)SQL Error (2013)連接錯(cuò)誤的解決方法,2013錯(cuò)誤主要還是在于用戶的授權(quán)問題,需要的朋友可以參考下2016-06-06
MySQL MVVC多版本并發(fā)控制的實(shí)現(xiàn)詳解
在多版本并發(fā)控制中,為了保證數(shù)據(jù)操作在多線程過程中,保證事務(wù)隔離的機(jī)制,降低鎖競(jìng)爭(zhēng)的壓力,保證較高的并發(fā)量。在每開啟一個(gè)事務(wù)時(shí),會(huì)生成一個(gè)事務(wù)的版本號(hào),被操作的數(shù)據(jù)會(huì)生成一條新的數(shù)據(jù)行2022-08-08
MySQL系列之redo log、undo log和binlog詳解
這篇文章主要介紹了MySQL系列之redo log、undo log和binlog詳解,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-12-12
深入探究MySQL事務(wù)實(shí)現(xiàn)原理
數(shù)據(jù)庫(kù)事務(wù)是指一組數(shù)據(jù)庫(kù)操作,這些操作必須被視為一個(gè)不可分割的單元,要么全部執(zhí)行成功,要么全部失敗回滾,本文詳細(xì)的給大家介紹了MySQL事務(wù)的實(shí)現(xiàn)原理,對(duì)我們學(xué)習(xí)MySQL有一定的幫助,感興趣的同學(xué)可以跟著小編一起來探究2023-06-06

