InnoDB gap lock in MySQL _ MySQL

This article mainly introduces InnoDB gap locks in MySQL, reminding users to pay attention to deadlocks, for more information about how to troubleshoot deadlocks for a customer, I encountered an interesting situation including InnoDB gap locks. In non-insert write operations WHERE a WHERE clause does not match any rows, I expect that the transaction will not have a lock, but I am wrong. Let's take a look at this table and the example UPDATE.

mysql> SHOW CREATE TABLE preferences \G*************************** 1. row ***************************    Table: preferencesCreate Table: CREATE TABLE `preferences` ( `numericId` int(10) unsigned NOT NULL, `receiveNotifications` tinyint(1) DEFAULT NULL, PRIMARY KEY (`numericId`)) ENGINE=InnoDB DEFAULT CHARSET=latin11 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

The InnoDB status shows that the UPDATE holds an X lock on the primary index record:

---TRANSACTION 4A18101, ACTIVE 12 sec2 lock struct(s), heap size 376, 1 row lock(s)MySQL thread id 3, OS thread handle 0x7ff2200cd700, query id 35 localhost msandboxTrx read view will not see trx with id >= 4A18102, sees < 4A18102TABLE LOCK table `test`.`preferences` trx id 4A18101 lock mode IXRECORD LOCKS space id 31766 page no 3 n bits 72 index `PRIMARY` of table `test`.`preferences` trx id 4A18101 lock_mode X

That's why, Heikki explained in his bug report, which makes sense. I know it is difficult to fix it, but with a slight disgust, I want it to be differentiated. To complete this article, let me prove the deadlock mentioned above. in the following example, mysql1 is the first session and mysql2 is the other session. the query order is as follows:

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: 0mysql2> 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: 0mysql1> INSERT INTO preferences (numericId, receiveNotifications) VALUES ('1', '1'); -- This one goes into LOCK WAITmysql2> INSERT INTO preferences (numericId, receiveNotifications) VALUES ('2', '1');ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

Now you can see how easy it is to cause a deadlock, so you must avoid this situation-if the INSERT part of the transaction causes non-INSERT write operations to not match any rows, do not do this, use replace into or READ-COMMITTED transaction isolation.