程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> MySQL中InnoDB的間隙鎖成績

MySQL中InnoDB的間隙鎖成績

編輯:MySQL綜合教程

MySQL中InnoDB的間隙鎖成績。本站提示廣大學習愛好者:(MySQL中InnoDB的間隙鎖成績)文章只能為提供參考,不一定能成為您想要的結果。以下是MySQL中InnoDB的間隙鎖成績正文


 在為一個客戶消除逝世鎖成績時我碰到了一個風趣的包含InnoDB間隙鎖的情況。關於一個WHERE子句不婚配任何行的非拔出的寫操作中,我預期事務應當不會有鎖,但我錯了。讓我們看一下這張表及示例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

InnoDB狀況顯示這個UPDATE在主索引記載上持有了一個X鎖:
 
---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申報中做懂得釋,這很成心義,我曉得修復起來很艱苦,但略帶討厭地我又願望它能被差別化處置。為完成這篇文章,讓我證實下下面說到的逝世鎖情形,上面中mysql1是第一個會話,mysql2是另外一個,查詢的次序以下:
 

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

如今你看到招致逝世鎖是何等的輕易,是以必定要防止這類情形——假如來自於事務的INSERT部門招致非拔出的寫操作能夠不婚配任何行的話,不要如許做,應用REPLACE INTO或應用READ-COMMITTED事務隔離。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved