Deadlocks on inserts in Mysql - mysql

I'm using mysql 5.0.92. Recently, we have lots of deadlocks of inserts to one table, to which rows are inserted (and updated or deleted) relatively fast. I've researched the questions here in StackOverflow, the mysql documentation and forums, without understanding the issue. One of the things that puzzle me is the fact one of the tables does not lock any resource according to the innodb status.
Here is the output of SHOW INNODB STATUS:
*** (1) TRANSACTION:
TRANSACTION 0 2326105503, ACTIVE 0 sec, process no 18871, OS thread id 1078532416 inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1216, undo log entries 1
MySQL thread id 225129, query id 126720476 192.168.999.999 the-user update
insert into the_table (creation_date, expiration_date, iid, ma_c, ma_cid, ma_ed, ma_lat, ma_long, ma_ln, ma_sd, ma_sid, uid, id) values ('2011-08-30 16:54:18.0', '2011-09-01 23:59:59.0', 1001, '', 'US', '2011-09-01 23:59:59.0', 33.72, -92.61, 'CITY_CENTER', '2011-08-31 23:59:59.0', '', 1010, 'xxx')
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 15002 page no 5749 n bits 376 index `idx_iu` of table `the_db/the_table` trx id 0 2326105503 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;;
*** (2) TRANSACTION:
TRANSACTION 0 2326105502, ACTIVE 0 sec, process no 18871, OS thread id 1243085120 inserting, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1216, undo log entries 2
MySQL thread id 223875, query id 126720499 192.168.999.999 the-user update
insert into the_table (creation_date, expiration_date, iid, ma_c, ma_cid,ma_ed, ma_lat, ma_long, ma_ln,ma_sd, ma_sid, uid, id) values ('2011-08-30 16:54:18.0','2011-12-14 23:59:59.0', 2002, 'Amsterdam', 'NL', '2011-10-04 16:45:00.0', 52.37, 4.89, 'CITY_CENTER', '2011-09-06 23:59:59.0', '', 2020, 'yyy')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 15002 page no 5749 n bits 376 index `idx_iu` of table `the_db/the_table` trx id 0 2326105502 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 283 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
0: len 8; hex 80000000008b22f0; asc " ;; 1: len 4; hex 8004ab2a; asc *;; 2: len 30; hex 313331343732333235383338393330353936323430363039352020202020; asc 1314723258389305962406095 ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 15002 page no 5749 n bits 376 index `idx_iu` of table `the_db/the_table` trx id 0 2326105502 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 (1)
The table is defined as follows:
CREATE TABLE `the_table` (
`id` char(30) NOT NULL default '',
`iid` bigint(20) NOT NULL,
`uid` int(11) NOT NULL,
`creation_date` datetime default NULL,
`expiration_date` datetime default NULL,
`ma_sd` datetime default NULL,
`ma_ed` datetime default NULL,
`ma_c` varchar(255) default NULL,
`ma_sid` varchar(3) default NULL,
`ma_cid` varchar(3) default NULL,
`ma_long` double default NULL,
`ma_lat` double default NULL,
`ma_ln` varchar(50) default NULL,
PRIMARY KEY (`id`),
KEY `idx_iu` (`iid`,`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
Help will be much appreciated.

Usually deadlocks occur when you have different transactions using the same tables, but when the tables are changed in a different order.
E.g. If transaction 1 updates table 1 and then table 2 and if there is another transaction which updates table 2 first and then table 1, then if these transactions are running frequently, you can get deadlocks.

Related

why deadlock occures when insert?

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.

How would this deadlock happens?

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)

Deadlock when insert on duplicate key update sql using on multi unique key

Is sql like insert ... on duplicate key update will generate gap locks on every unique key index/primary key, disordered, when the row is not in table?
I found that when using multi transactions to execute insert on duplicate key update sql on table with more than one unique key may cause deadlock.
My table was like:
| Table | Create Table
| test | CREATE TABLE `test1` (
`c1` int(11) NOT NULL,
`c2` int(11) DEFAULT NULL,
`c3` int(11) DEFAULT NULL,
PRIMARY KEY (`c1`),
UNIQUE KEY `uk` (`c2`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
After the deadlock arise,I got engine innodb status:
------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-12-06 20:01:57 0x70000ee06000
*** (1) TRANSACTION:
TRANSACTION 2219555, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 6686, OS thread handle 123145569476608, query id 6114936 localhost 127.0.0.1 root update
INSERT INTO test1 (`c1`, `c2`, `c3`) VALUES (15538, 1213457428, 30) ON DUPLICATE KEY UPDATE `c3` = VALUES(`c3`)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 65 page no 29 n bits 848 index cc of table `compare_db`.`test1` trx id 2219555 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 749 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 4; hex c88c97bb; asc ;;
1: len 4; hex 80002c42; asc ,B;;
*** (2) TRANSACTION:
TRANSACTION 2219538, ACTIVE 0 sec inserting
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 6631, OS thread handle 123145551896576, query id 6114889 localhost 127.0.0.1 root update
INSERT INTO test1 (`c1`, `c2`, `c3`) VALUES (535, 1215380840, 30) ON DUPLICATE KEY UPDATE `c3` = VALUES(`c3`)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 65 page no 29 n bits 840 index cc of table `compare_db`.`test1` trx id 2219538 lock_mode X locks gap before rec
Record lock, heap no 749 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 4; hex c88c97bb; asc ;;
1: len 4; hex 80002c42; asc ,B;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 65 page no 29 n bits 848 index cc of table `compare_db`.`test1` trx id 2219538 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 749 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 4; hex c88c97bb; asc ;;
1: len 4; hex 80002c42; asc ,B;;
*** WE ROLL BACK TRANSACTION (1)
It would be just fine when insert directly.
So I was thinking, is that because the two session both happened to locked gap (a, b) on uk, and (c, d) on primary key when deadlock arose, but with different order.
Is anyone knows the real reason?

Can anyone explain my mysql deadlock condition?

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
|

An insert caused a deadlock in InnoDB. How did this happen?

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