Recently I am handing a SQL issue, I have two transaction, the transaction A first got the Next-Key Locks, and the transaction B tried to get the same lock, so it was waiting, then the transaction A tried to get Insert Intention Locks, so the deadlock happened. But I am confuse that why would this happens?
Here is my table structure:
CREATE TABLE `changeset` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT',
`userId` int(10) NOT NULL COMMENT,
`documentId` varchar(20) NOT NULL,
`memberId` bigint(13) NOT NULL,
`createTime` bigint(13) NOT NULL,
`version` bigint(13) NOT NULL COMMENT,
`changesets` mediumtext,
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_documentId_version` (`documentId`,`version`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=85771623 DEFAULT CHARSET=utf8
And here is my deadlock log:
(1) TRANSACTION:
TRANSACTION 22640, ACTIVE 66 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 209, OS thread handle 123145559986176, query id 6204
localhost root Sending data
select * from changeset where documentId = '7oO5C_v' and version >=
13 for update
(1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 107 page no 15 n bits 704 index
uniq_documentId_version of table test.changeset trx id 22640
lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format;
info bits 0
0: len 7; hex 3976735431644a; asc 9vsT1dJ;;
1: len 8; hex 8000000000000000; asc ;;
2: len 4; hex 051cbef7; asc ;;
(2) TRANSACTION:
TRANSACTION 22639, ACTIVE 95 sec inserting
mysql tables in use 1, locked 1
6 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 1
MySQL thread id 212, OS thread handle 123145561657344, query id 6210
localhost root update insert into changeset values (0, 9, '7oO5C_v',
814, 1, 13, 'x')
(2) HOLDS THE LOCK(S):
RECORD LOCKS space id 107 page no 15 n bits 704 index
uniq_documentId_version of table test.changeset trx id 22639
lock_mode X
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format;
info bits 0
0: len 7; hex 3976735431644a; asc 9vsT1dJ;;
1: len 8; hex 8000000000000000; asc ;;
2: len 4; hex 051cbef7; asc ;;
(2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 107 page no 15 n bits 704 index
uniq_documentId_version of table test.changeset trx id 22639
lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format;
info bits 0
0: len 7; hex 3976735431644a; asc 9vsT1dJ;;
1: len 8; hex 8000000000000000; asc ;;
2: len 4; hex 051cbef7; asc ;;
WE ROLL BACK TRANSACTION (1)
Have you used "(nolock) " in your selects?
Select * From Table with (nolock)
Related
I have a table defined in this way:
CREATE TABLE `measure` (
`measureId` bigint NOT NULL,
`sensorId` int NOT NULL,
`timestamp` bigint NOT NULL,
`data` float NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;
ALTER TABLE `measure`
ADD PRIMARY KEY (`measureId`),
ADD KEY `measure_index` (`sensorId`,`timestamp`);
ALTER TABLE `measure`
MODIFY `measureId` bigint NOT NULL AUTO_INCREMENT;
measureId is mostly used as auto increment, but sometimes I need to specify measureId during insert. I use the following transaction for my application:
begin;
select max(measureId) from measure for update;
-- use the max id retrieved to create measurements
insert into measure values (max_id + 1, ...), (max_id + 2, ...), ...;
-- do other stuff
commit;
I use select ... for update to avoid insertions between selecting max(measureId) and and adding the new rows. Without using it, the transaction would fail since the id would be already taken via autoincrement (I use the default isolation REPEATABLE READS).
In a non concurrent environment the transaction succeeds, but I get a deadlock when this happens between two transactions:
T1: select max(measureId) ...;
T2: select max(measureId) ...; -- starts waiting
T1: into measure values (max_id + 1, ...), ...;
-- ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
Why should this be a dealock? T1 should already have the lock on the primary key index (link).
How can i fix this?
Edit: Added output of the innodb status monitor, not sure what is happening. I seems to me that transaction 2 (below) is waiting for a lock it already has.
------------------------
LATEST DETECTED DEADLOCK
------------------------
2023-01-23 13:58:10 139850373236480
*** (1) TRANSACTION:
TRANSACTION 41530, ACTIVE 62 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1128, 2 row lock(s)
MySQL thread id 1251, OS thread handle 139850310264576, query id 5030779 172.19.0.1 root optimizing
select max(measureId) from measure for update
*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 177 page no 22722 n bits 360 index PRIMARY of table `WEATHER_STATION`.`measure` trx id 41530 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 177 page no 22722 n bits 360 index PRIMARY of table `WEATHER_STATION`.`measure` trx id 41530 lock_mode X waiting
Record lock, heap no 290 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len 8; hex 80000000004aa795; asc J ;;
1: len 6; hex 00000000a1f8; asc ;;
2: len 7; hex 82000000a913e6; asc ;;
3: len 4; hex 80000192; asc ;;
4: len 8; hex 8000000063cac0ed; asc c ;;
5: len 4; hex 6666ea41; asc ff A;;
*** (2) TRANSACTION:
TRANSACTION 41529, ACTIVE 163 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1128, 3 row lock(s)
MySQL thread id 1250, OS thread handle 139850312378112, query id 5030780 172.19.0.1 root update
insert into measure values (4892566, 1, 2, 3)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 177 page no 22722 n bits 360 index PRIMARY of table `WEATHER_STATION`.`measure` trx id 41529 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 290 PHYSICAL RECORD: n_fields 6; compact format; info bits 0
0: len 8; hex 80000000004aa795; asc J ;;
1: len 6; hex 00000000a1f8; asc ;;
2: len 7; hex 82000000a913e6; asc ;;
3: len 4; hex 80000192; asc ;;
4: len 8; hex 8000000063cac0ed; asc c ;;
5: len 4; hex 6666ea41; asc ff A;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 177 page no 22722 n bits 360 index PRIMARY of table `WEATHER_STATION`.`measure` trx id 41529 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
*** WE ROLL BACK TRANSACTION (2)
Instead, get rid of measureid:
CREATE TABLE `measure` (
`sensorId` int NOT NULL,
`timestamp` bigint NOT NULL,
`data` float NOT NULL,
PRIMARY KEY(sensorId, timestamp)
) ENGINE=InnoDB
Consider using the TIMESTAMP(n) datatype, where n is the number of decimal places (fraction of a second). The max is 6 (microseconds). This will give you a variety of date/time functions that will probably be clearer than futzing with a BIGINT.
Suggest shrinking sensorId to a smaller datatype. For example, SMALLINT UNSIGNED would allow 65K sensors in a 2-byte column.
With those changes, the table (data+indexes) will take about half the disk space. This will have a favorable impact on speed.
With that, you won't need the SELECT (another speedup). And you can possibly do nothing more than the multi-row INSERT.
mysql/innodb, repeatable read transaction, deadlock on deletion of non intercepting rows. Trying to understand what is happening.
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-05-08 06:16:23 7f4a5769a700
*** (1) TRANSACTION:
TRANSACTION 12314813, ACTIVE 1 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 13 lock struct(s), heap size 2936, 355 row lock(s), undo log entries 110
MySQL thread id 1654182, OS thread handle 0x7f4a57658700, query id 21892885 xx.xx.xx.xx oc5z updating
DELETE FROM deal_product_rows_tmp WHERE batch_no=5754
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 219 page no 3 n bits 168 index `PRIMARY` of table `db1`.`deal_product_rows_tmp` trx id 12314813 lock_mode X waiting
Record lock, heap no 88 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
0: len 4; hex 80001bb9; asc ;;
1: len 6; hex 000000bbe8c0; asc ;;
2: len 7; hex be000001b50110; asc ;;
3: len 4; hex 8000167b; asc {;;
4: len 4; hex 800fe7c4; asc ;;
5: len 4; hex 80002516; asc % ;;
6: len 4; hex 8000986e; asc n;;
7: len 4; hex 80000003; asc ;;
8: len 30; hex 415254455820d184d0bed180d0bcd18b20d0bfd180d18fd0bcd0bed183d0; asc PROD ; (total 81 bytes);
9: len 8; hex 0000000000208c40; asc #;;
10: len 1; hex 4d; asc M;;
*** (2) TRANSACTION:
TRANSACTION 12314816, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
14 lock struct(s), heap size 2936, 95 row lock(s), undo log entries 14
MySQL thread id 1654175, OS thread handle 0x7f4a5769a700, query id 21892888 xx.xx.xx.xx oc5z updating
DELETE FROM deal_product_rows_tmp WHERE batch_no=5755
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 219 page no 3 n bits 168 index `PRIMARY` of table `db1`.`deal_product_rows_tmp` trx id 12314816 lock_mode X locks rec but not gap
Record lock, heap no 25 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
Table structure:
CREATE TABLE `deal_product_rows_tmp` (
`batch_no` int(11) NOT NULL,
`bitrix_id` int(11) NOT NULL,
`deal_id` int(11) NOT NULL,
`product_id` int(11) NOT NULL,
`quantity` int(11) NOT NULL,
`product_name` varchar(1000) NOT NULL,
`price` double DEFAULT NULL,
`status` varchar(50) NOT NULL,
`tmp_id` int(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (`tmp_id`),
KEY `idx_deal_row_tmp_deal` (`deal_id`),
KEY `idx_deal_row_tmp_batchno` (`batch_no`)
) ENGINE=InnoDB AUTO_INCREMENT=7500 DEFAULT CHARSET=utf8
Did I understand correctly: first transaction trying to apply gap lock on all rows at index page. one by one record (Next-Key Locks). Second transaction trying the same, but in different direction. In result part of index page locked by transaction 1, part by transaction 2.
I'm understand that I can reduce transaction isolation level to RC, I'm trying to understand how the repeatable read works in innodb.
UPDATE: same situation with Read Committed IL.
Confused about deadlock where execute inserting,while I seem to have hold the same lock before.
Mysql5.6,Innodb engin,Read Commited.
CREATE TABLE `tb_test` (
`id` INT(11) NOT NULL AUTO_INCREMENT,
`user_id` INT(11) NOT NULL,
`name` VARCHAR(50) NOT NULL DEFAULT '0',
`md_time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`data` BLOB NULL DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE INDEX `user_id` (`user_id`)
)
COLLATE='latin1_swedish_ci'
ENGINE=InnoDB
AUTO_INCREMENT=1
;
insert into tb_test (user_id) values (0);
Here are how deadlock happens:
tx1:start transaction;
tx1:SELECT * FROM tb_test WHERE user_id = 0 FOR UPDATE;
tx2:start transaction;
tx2:SELECT * FROM tb_test WHERE user_id = 0 FOR UPDATE;//blocking
tx1:insert into tb_test (user_id) values (0) on duplicate key update name = 'name';////deadlock occurs
I think tx1 acquired the X lock on index user_id with value 0 aenter code herefter execute the first sql,and tx2 is blocking,why tx1 get deadlock where try to aquire the same X lock already acquired?Please help.
The deadlock log is:
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-03-27 10:01:34 0x560
*** (1) TRANSACTION:
TRANSACTION 176686, ACTIVE 3 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 791, OS thread handle 13064, query id 16596 127.0.0.1 root Statistics
SELECT * FROM tb_test WHERE user_id = 0 FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1067 page no 4 n bits 72 index user_id of table `test`.`tb_test` trx id 176686 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 4; hex 80000000; asc ;;
1: len 4; hex 80000001; asc ;;
*** (2) TRANSACTION:
TRANSACTION 176685, ACTIVE 3 sec inserting, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 790, OS thread handle 1376, query id 16597 127.0.0.1 root Update
insert into tb_test (user_id) values (0) ON DUPLICATE KEY UPDATE NAME = '1'
#SELECT * FROM tb_test WHERE user_id = 0 LOCK IN SHARE MODE
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1067 page no 4 n bits 72 index user_id of table `test`.`tb_test` trx id 176685 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 4; hex 80000000; asc ;;
1: len 4; hex 80000001; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1067 page no 4 n bits 72 index user_id of table `test`.`tb_test` trx id 176685 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 4; hex 80000000; asc ;;
1: len 4; hex 80000001; asc ;;
*** WE ROLL BACK TRANSACTION (1)
Isn't it the same the lock tx2 is holding and the one it is waiting for?
tx1 failed because the update status is really happening and tx2 has an intent lock.
Take a look at SELECT * FROM performance_schema.data_locks at each stage of your transaction.
I have a couple of questions regarding mysql dead lock.
I don't understand why below insert queries goes into deadlock condition.
Both are same query but they have different PK value and UNIQUE Key value.(must be different row)
TX1 : insert into deadlocktable (a, b, c, d, e, id) values (1, 1453004563, 'gerg354g3g54fgrg45g4rgt4t4t4ft4f4fff', '23r23r232rr23r23r3refserwewfswe', 22342432343, 'sdlkfj30fji0')
TX2 : insert into deadlocktable (a, b, c, d, e, id) values (1, 1453004563, 'skfjskfjsdkfjsdkfjsdkfdjskfdkffd', 'erg34geg4ewg34fg4g4g4grffsdfew', 34343t6543343, 'dfsdggrg')
My question goes..
Why TX1 requires S lock on the table when inserting ?
Why do they require same lock? (id 1126 page no 1121626 n bits 240 index ix_1)
My understanding goes
TX2 got X lock on the position for updating
TX1 wants to get same lock with the one TX2 got. So TX1 is waiting..
TX2 wants to get same lock with gap. Why does it need gap lock as well?
Can anyone explain my question?
mysql deadlock detector found like below
(1) TRANSACTION:
TRANSACTION 61201547464, ACTIVE 1 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 7 lock struct(s), heap size 1184, 5 row lock(s), undo log entries 3 MySQL thread id 5551783, OS thread handle 0x2b463b79d700, query id 100234460104 192.168.0.4 dbuser update
insert into deadlocktable (a, b, c, d, e, id) values (1, 1453004563, 'gerg354g3g54fgrg45g4rgt4t4t4ft4f4fff', '23r23r232rr23r23r3refserwewfswe', 22342432343, 'sdlkfj30fji0')
(1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1126 page no 1121626 n bits 240 index `ix_1` of table `mydb`.`deadlocktable` trx id 61201547464 lock mode S waiting Record lock, heap no 170 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 8; hex 0000092f98cc6435; asc / d5;;
1: len 30; hex 234385385390853853858423584235930485923085892305842390843048; asc skfjskfjsdkfjsdkfjsdkfdjskfdkf; (total 36 bytes);
2: len 30; hex 344375894375389475894353894897539847589375893748953745738945; asc sdklfjskldfjsdkfjsklfsdklfjsdk; (total 36 bytes);
(2) TRANSACTION:
TRANSACTION 61201547752, ACTIVE 1 sec inserting, thread declared inside InnoDB 5000 mysql tables in use 1, locked 1
7 lock struct(s), heap size 1184, 6 row lock(s), undo log entries 3 MySQL thread id 5550461, OS thread handle 0x2b4642d2c700, query id 100234460128 192.168.168.7 dbuser update
insert into deadlocktable (a, b, c, d, e, id) values (1, 1453004563, 'skfjskfjsdkfjsdkfjsdkfdjskfdkffd', 'erg34geg4ewg34fg4g4g4grffsdfew', 34343t6543343, 'dfsdggrg')
(2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1126 page no 1121626 n bits 240 index `ix_1` of table `mydb`.`deadlocktable` trx id 61201547752 lock_mode X locks rec but not gap Record lock, heap no 170 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 8; hex 0000092f98cc6435; asc / d5;;
1: len 30; hex 234385385390853853858423584235930485923085892305842390843048; asc skfjskfjsdkfjsdkfjsdkfdjskfdkf; (total 36 bytes);
2: len 30; hex 344375894375389475894353894897539847589375893748953745738945; asc sdklfjskldfjsdkfjsklfsdklfjsdk; (total 36 bytes);
(2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1126 page no 1121626 n bits 240 index `ix_1` of table `mydb`.`deadlocktable` trx id 61201547752 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 170 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 8; hex 0000092f98cc6435; asc / d5;;
1: len 30; hex 234385385390853853858423584235930485923085892305842390843048; asc skfjskfjsdkfjsdkfjsdkfdjskfdkf; (total 36 bytes);
2: len 30; hex 344375894375389475894353894897539847589375893748953745738945; asc sdklfjskldfjsdkfjsklfsdklfjsdk; (total 36 bytes);
Table schema is
CREATE TABLE `deadlocktable` (
`id` varchar(36) NOT NULL,
`c` char(36) NOT NULL,
`b` int(11) NOT NULL DEFAULT '0',
`a` tinyint(1) NOT NULL DEFAULT '1',
`d` varchar(50) DEFAULT 'defaultSessionId',
`e` bigint(15) unsigned zerofill NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `ix_1` (`e`,`c`),
KEY `ix_2` (`b`),
KEY `ix_3` (`c`),
KEY `ix_4` (`e`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
|
My question is this: Why does transaction 1 hold the primary lock and why does transaction 2 need primary lock? I can't find any information about this lock in mysql manual.
Information about this deadlock:
transaction 1:
1988266681 Query BEGIN
1988266681 Query INSERT IGNORE INTO `tab1`
(`sn`, `is_fetch`, `is_done`, `add_time`)
VALUES ('4287', 0, 0, 1403186277)
1988266681 Query COMMIT
transaction 2:
1988212988 Query BEGIN
1988212988 Query SELECT sn FROM tab1 WHERE is_fetch = 0
LIMIT 200 FOR UPDATE
1988212988 Query UPDATE `tab1` SET `is_fetch` = 1
WHERE sn in ('4287', '4387', '4487', '4587', '4687',
'4787', '4887', '4987')
1988212988 Query COMMIT
schema info:
CREATE TABLE `tab1` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`sn` varchar(20) NOT NULL,
`is_fetch` tinyint(1) NOT NULL DEFAULT '0' ,
`is_done` tinyint(1) NOT NULL DEFAULT '0' ,
`add_time` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `sn` (`sn`),
KEY `is_fetch` (`is_fetch`),
KEY `is_done` (`is_done`)
) ENGINE=InnoDB AUTO_INCREMENT=4387619 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;
deadlock infoļ¼
------------------------
LATEST DETECTED DEADLOCK
------------------------
140617 23:25:36
*** (1) TRANSACTION:
TRANSACTION 36E4099DA, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1248, 2 row lock(s), undo log entries 1
MySQL thread id 1937033606, OS thread handle 0x2ae3b0040700, query id 18031163883 192.168.1.65 db1 update
INSERT IGNORE INTO `tab1` (`sn`, `is_fetch`, `is_done`, `add_time`) VALUES ('1887', 0, 0, 1403018736)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 625 page no 5 n bits 1616 index `is_fetch` of table `db1`.`tab1` trx id 36E4099DA lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 1476 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc ;;
1: len 4; hex 80410669; asc A i;;
*** (2) TRANSACTION:
TRANSACTION 36E4099D7, ACTIVE 0 sec fetching rows, thread declared inside InnoDB 458
mysql tables in use 1, locked 1
6 lock struct(s), heap size 3112, 51 row lock(s), undo log entries 7
MySQL thread id 1937007092, OS thread handle 0x2ae8b5a26700, query id 18031163880 192.168.1.130 db1 Updating
UPDATE `tab1` SET `is_fetch` = 1 WHERE sn in ('1187', '1287', '1387', '1487', '1587', '1687', '1787')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 625 page no 5 n bits 1616 index `is_fetch` of table `db1`.`tab1` trx id 36E4099D7 lock_mode X locks gap before rec
Record lock, heap no 1476 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 81; asc ;;
1: len 4; hex 80410669; asc A i;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 625 page no 3 n bits 440 index `PRIMARY` of table `db1`.`tab1` trx id 36E4099D7 lock_mode X waiting
Record lock, heap no 168 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
0: len 4; hex 80411598; asc A ;;
1: len 6; hex 00036e4099da; asc n# ;;
2: len 7; hex e80000c0060110; asc ;;
3: len 14; hex 3134303631373338343331383837; asc 1887;;
4: len 1; hex 80; asc ;;
5: len 1; hex 80; asc ;;
6: len 4; hex d3a05df0; asc ] ;;
Q: How did this happen?
Transaction 2 obtained an exclusive lock on records in the 'is_fetch` index, and attempted to obtain a lock on records in the PRIMARY key of the table.
Transaction 1 obtained an exclusive lock on records in the PRIMARY key of the table, and attempted to obtain a lock on records in the is_fetch index.
InnoDB automatically detects that neither transaction can proceed, because each is holding resources needed by the other. InnoDB terminates one of the transactions so the other transaction can proceed.
Note that an INSERT statement can obtain a "gaps" lock for records in unique indexes. It's not just INSERT that caused the deadlock, it was the combination of transactions that were running concurrently.
InnoDB record locking is documented in the MySQL Reference manual here:
http://dev.mysql.com/doc/refman/5.5/en/innodb-record-level-locks.html
SELECT ... FOR UPDATE acquire lock for scanned rows. You can reed more here: http://dev.mysql.com/doc/refman/5.0/en/innodb-locks-set.html and here http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html