Mysql Unique Key Causes Dead Lock - mysql

There are two tables stream_lineage_node and stream_lineage_node_relation. The following are the table definitions :
CREATE TABLE `stream_lineage_node` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
`node_key` varchar(255) NOT NULL DEFAULT '' COMMENT '血缘节点主键',
`node_type` varchar(255) NOT NULL DEFAULT '' COMMENT '血缘节点类型',
`node_desc` varchar(255) NOT NULL DEFAULT '' COMMENT '血缘节点描述',
`properties` text COMMENT '血缘节点属性',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_node_key` (`node_key`),
KEY `idx_node_type` (`node_type`)
) ENGINE=InnoDB AUTO_INCREMENT=30705119 DEFAULT CHARSET=utf8mb4 COMMENT='stream血缘节点表'
CREATE TABLE `stream_lineage_node_relation` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
`node_key` varchar(255) NOT NULL DEFAULT '' COMMENT '血缘节点',
`next_node_key` varchar(255) NOT NULL DEFAULT '' COMMENT '血缘下游节点',
`relation_type` varchar(255) NOT NULL DEFAULT '' COMMENT '关系类型',
`properties` text COMMENT '血缘节点属性',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_key_next_key_type` (`node_key`,`next_node_key`,`relation_type`),
KEY `idx_next_node_key` (`next_node_key`),
KEY `idx_relation_type` (`relation_type`)
) ENGINE=InnoDB AUTO_INCREMENT=15100909 DEFAULT CHARSET=utf8mb4 COMMENT='stream血缘节点关系表'
The mysql dead lock occurs when the code invokes the following sql statements continuously in a single transaction and concurrent environment..
delete from stream_lineage_node where node_key = ? and node_type = ?
delete from stream_lineage_node_relation where next_node_key= ? and relation_type = ?
insert ignore into stream_lineage_node (node_key, node_type, node_desc, properties) values (?, ?, ?, ?), (?, ?, ?, ?)
insert ignore into stream_lineage_node_relation (node_key, next_node_key, relation_type, properties) values (?, ?, ?, ?)
The following is the mysql dead lock log.
show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2021-03-31 10:54:36 0x7f920577d700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 14 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 24286472 srv_active, 0 srv_shutdown, 7912821 srv_idle
srv_master_thread log flush and writes: 32199293
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 133475212
OS WAIT ARRAY INFO: signal count 263184954
RW-shared spins 0, rounds 309901947, OS waits 29849278
RW-excl spins 0, rounds 2276291003, OS waits 14249998
RW-sx spins 60882058, rounds 988222500, OS waits 11577714
Spin rounds per wait: 309901947.00 RW-shared, 2276291003.00 RW-excl, 16.23 RW-sx
------------------------
LATEST DETECTED DEADLOCK
------------------------
2021-03-31 10:50:14 0x7f92d6fff700
*** (1) TRANSACTION:
TRANSACTION 10074319369, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 10 lock struct(s), heap size 1136, 8 row lock(s), undo log entries 3
MySQL thread id 16878758, OS thread handle 140286635210496, query id 14914572875 10.83.189.15 datastudio#dd update
insert ignore into stream_lineage_node (node_key, node_type, node_desc, properties)
values
(
'DRUID_engine_duse_stg_broad_top20',
'DRUID',
'engine_duse_stg_broad_top20',
'{\"datasourceName\":\"engine_duse_stg_broad_top20\",\"woaterDatasourceId\":\"24013\",\"woaterDatasourceIntro\":\"fmt_01\",\"woaterDatasourceTitle\":\"stg数据源\"}'
)
,
(
'KAFKA_28_w_duse_stg_top20_broadcast',
'KAFKA',
'w_duse_stg_top20_broadcast',
'{\"brokers\":\"10.8.8.14:30372\",\"clusterId\":\"28\",\"groupId\":\"\",\"topic\":\"w_duse_stg_top20_broadcast\"}'
)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 338 page no 1143 n bits 392 index uniq_node_key of table `datastudio`.`stream_lineage_node` trx id 10074319369 lock mode S waiting
Record lock, heap no 145 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 30; hex 44525549445f656e67696e655f647573655f7374675f6d6f6e69746f725f; asc DRUID_engine_duse_stg_monitor_; (total 43 bytes);
1: len 8; hex 0000000001c96f18; asc o ;;
*** (2) TRANSACTION:
TRANSACTION 10074319368, ACTIVE 0 sec inserting, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
15 lock struct(s), heap size 1136, 13 row lock(s), undo log entries 4
MySQL thread id 16879827, OS thread handle 140268649051904, query id 14914572881 10.83.189.15 datastudio#dd update
insert ignore into stream_lineage_node_relation (node_key, next_node_key, relation_type, properties)
values
(
'KAFKA_28_w_duse_stg_order_booking_assign',
'DRUID_engine_duse_stg_monitor_bookingAssign',
'STREAM_DRUID',
'{\"clusterId\":\"28\",\"datasourceName\":\"engine_duse_stg_monitor_bookingAssign\",\"topic\":\"w_duse_stg_order_booking_assign\"}'
)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 338 page no 1143 n bits 392 index uniq_node_key of table `datastudio`.`stream_lineage_node` trx id 10074319368 lock_mode X locks rec but not gap
Record lock, heap no 145 PHYSICAL RECORD: n_fields 2; compact format; info bits 32
0: len 30; hex 44525549445f656e67696e655f647573655f7374675f6d6f6e69746f725f; asc DRUID_engine_duse_stg_monitor_; (total 43 bytes);
1: len 8; hex 0000000001c96f18; asc o ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 339 page no 3029 n bits 248 index uniq_key_next_key_type of table `datastudio`.`stream_lineage_node_relation` trx id 10074319368 lock mode S waiting
Record lock, heap no 165 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 30; hex 4b41464b415f32385f775f647573655f7374675f746f7032305f62726f61; asc KAFKA_28_w_duse_stg_top20_broa; (total 35 bytes);
1: len 30; hex 44525549445f656e67696e655f647573655f7374675f62726f61645f746f; asc DRUID_engine_duse_stg_broad_to; (total 33 bytes);
2: len 12; hex 53545245414d5f4452554944; asc STREAM_DRUID;;
3: len 8; hex 0000000000e0cade; asc ;;
*** WE ROLL BACK TRANSACTION (1)
Can someone help me explain the dead lock reason ? And how to solve the problem ? Thank You !

Related

mysql select for update read committed deadlock

mysql version:5.7.23-log
isolation level:read committed
mysql data
SET FOREIGN_KEY_CHECKS=0;
-- ----------------------------
-- Table structure for app_record_lock_test
-- ----------------------------
DROP TABLE IF EXISTS `app_record_lock_test`;
CREATE TABLE `app_record_lock_test` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`hash` bigint(20) NOT NULL DEFAULT '0',
`cluster` varchar(256) NOT NULL,
`namespace` varchar(256) NOT NULL DEFAULT '',
`service` varchar(256) NOT NULL DEFAULT '',
`pod` varchar(256) NOT NULL DEFAULT '',
`created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
`updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `cluster_hash` (`cluster`,`hash`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=120236025 DEFAULT CHARSET=utf8;
-- ----------------------------
-- Records of app_record_lock_test
-- ----------------------------
INSERT INTO `app_record_lock_test` VALUES ('120236012', '1', 'cluster', 'namespace', 'service', 'pod', '2022-02-18 14:14:59', '2022-02-09 10:00:00');
INSERT INTO `app_record_lock_test` VALUES ('120236013', '2', 'cluster', 'namespace', 'service', 'pod', '2022-02-18 14:14:59', '2022-02-09 10:00:00');
INSERT INTO `app_record_lock_test` VALUES ('120236014', '3', 'cluster', 'namespace', 'service', 'pod', '2022-02-18 14:14:59', '2022-02-09 10:00:00');
session 1:
START TRANSACTION;
SELECT HASH
FROM
app_record_lock_test
WHERE
cluster = 'cluster' FOR UPDATE;
INSERT INTO app_record_lock_test ( HASH, cluster, namespace, service, pod, updated_at )
VALUES
( 1, 'cluster', 'namespace', 'service', 'pod', '2022-02-09 10:00:00' )
ON DUPLICATE KEY UPDATE updated_at = '2022-02-09 11:00:01';
COMMIT;
session 2:
START TRANSACTION;
SELECT HASH
FROM
app_record_lock_test
WHERE
cluster = 'cluster' FOR UPDATE;
INSERT INTO app_record_lock_test ( HASH, cluster, namespace, service, pod, updated_at )
VALUES
( 1, 'cluster', 'namespace', 'service', 'pod', '2022-02-09 10:00:00' )
ON DUPLICATE KEY UPDATE updated_at = '2022-02-09 11:00:01';
COMMIT;
Steps to reproduce
1、session 1 first execute select for update
2、session 2 execute select for update
3、session 1 executes insert,This is session 2 and an error will be reported
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
why is this?
show engine innodb status,before insert:
------------------------
LATEST DETECTED DEADLOCK
------------------------
2022-02-21 16:13:48 0x7f2026049700
*** (1) TRANSACTION:
TRANSACTION 421085334, ACTIVE 8 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 41539545, OS thread handle 139773723899648, query id 20729357470 10.190.176.247 console Sending data
/* ApplicationName=DBeaver 21.3.5 - SQLEditor <Script-8.sql> */ SELECT HASH
FROM
app_record_lock_test
WHERE
cluster = 'cluster' FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 12005 page no 4 n bits 72 index cluster_hash of table `console`.`app_record_lock_test` trx id 421085334 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 7; hex 636c7573746572; asc cluster;;
1: len 8; hex 8000000000000001; asc ;;
2: len 4; hex 872aa7ec; asc * ;;
*** (2) TRANSACTION:
TRANSACTION 421085333, ACTIVE 13 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 41539561, OS thread handle 139776053516032, query id 20729357538 10.190.176.247 console update
/* ApplicationName=DBeaver 21.3.5 - SQLEditor <Script-5.sql> */ INSERT INTO app_record_lock_test ( HASH, cluster, namespace, service, pod, updated_at )
VALUES
( 1, 'cluster', 'namespace', 'service', 'pod', '2022-02-09 10:00:00' )
ON DUPLICATE KEY UPDATE updated_at = '2022-02-09 11:00:01'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 12005 page no 4 n bits 72 index cluster_hash of table `console`.`app_record_lock_test` trx id 421085333 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 7; hex 636c7573746572; asc cluster;;
1: len 8; hex 8000000000000001; asc ;;
2: len 4; hex 872aa7ec; asc * ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 12005 page no 4 n bits 72 index cluster_hash of table `console`.`app_record_lock_test` trx id 421085333 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 7; hex 636c7573746572; asc cluster;;
1: len 8; hex 8000000000000001; asc ;;
2: len 4; hex 872aa7ec; asc * ;;
*** WE ROLL BACK TRANSACTION (1)
after insert:
------------------------
LATEST DETECTED DEADLOCK
------------------------
2022-02-22 09:26:16 0x7f216925a700
*** (1) TRANSACTION:
TRANSACTION 421416755, ACTIVE 22 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 41565582, OS thread handle 139778307692288, query id 20731658463 10.190.176.247 console Sending data
/* ApplicationName=DBeaver 21.3.5 - SQLEditor <Script-8.sql> */ SELECT HASH
FROM
app_record_lock_test
WHERE
cluster = 'cluster' FOR UPDATE
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 12005 page no 4 n bits 72 index cluster_hash of table `console`.`app_record_lock_test` trx id 421416755 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 7; hex 636c7573746572; asc cluster;;
1: len 8; hex 8000000000000001; asc ;;
2: len 4; hex 872aa7ec; asc * ;;
*** (2) TRANSACTION:
TRANSACTION 421416754, ACTIVE 26 sec inserting
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1136, 7 row lock(s), undo log entries 1
MySQL thread id 41565555, OS thread handle 139781474723584, query id 20731658615 10.190.176.247 console update
/* ApplicationName=DBeaver 21.3.5 - SQLEditor <Script-5.sql> */ INSERT INTO app_record_lock_test ( HASH, cluster, namespace, service, pod, updated_at )
VALUES
( 1, 'cluster', 'namespace', 'service', 'pod', '2022-02-09 10:00:00' )
ON DUPLICATE KEY UPDATE updated_at = '2022-02-09 11:00:01'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 12005 page no 4 n bits 72 index cluster_hash of table `console`.`app_record_lock_test` trx id 421416754 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 7; hex 636c7573746572; asc cluster;;
1: len 8; hex 8000000000000001; asc ;;
2: len 4; hex 872aa7ec; asc * ;;
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 7; hex 636c7573746572; asc cluster;;
1: len 8; hex 8000000000000002; asc ;;
2: len 4; hex 872aa7ed; asc * ;;
Record lock, heap no 4 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 7; hex 636c7573746572; asc cluster;;
1: len 8; hex 8000000000000003; asc ;;
2: len 4; hex 872aa7ee; asc * ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 12005 page no 4 n bits 72 index cluster_hash of table `console`.`app_record_lock_test` trx id 421416754 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 7; hex 636c7573746572; asc cluster;;
1: len 8; hex 8000000000000001; asc ;;
2: len 4; hex 872aa7ec; asc * ;;
*** WE ROLL BACK TRANSACTION (1)

INSERT ON DUPLICATE KEY UPDATE occurs a deadlock error, which is about record lock

I use insert ... on duplicate key updateto insert data in batches.
But I get a error when do it with more than one threads, actually just two threads do it.
The table is:
create table alarm {
id varchar(20) not null collate utf8_unicode_ci,
`date` date not null,
adas blob,
dsm blob,
bsd blob,
primary key(id, `date`)
) engine=innodb default charset=utf8
collate=utf8_unicode_ci
The insert statement is like:
insert into alarm(id, `date`, adas) values
('10001', 20220105, 0x1231231),
('10002', 20220105, 0xAFED001),
....
on duplicate key update
adas=concat(ifnull(adas,''), ifnull(values(adas),''));
The another insert statement is like:
insert into alarm(id, `date`, dsm) values
('10001', 20220105, 0x1231231),
('10002', 20220105, 0xAFED001),
('10008', 20220105, 0xAFED001),
('00008', 20220105, 0xAFED34),
....
on duplicate key update
dsm=concat(ifnull(dsm,''), ifnull(values(dsm),''));
sometimes, it will occur a dead lock error. The database log as following:
> myql show engine innodb status \G;
------------------------
LATEST DETECTED DEADLOCK
------------------------
2022-02-22 16:49:29 0x1fac
*** (1) TRANSACTION:
TRANSACTION 3902837, ACTIVE 1 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 23 lock struct(s), heap size 1080, 28 row lock(s), undo log entries 31
MySQL thread id 85930, OS thread handle 17464, query id 34130124 DESKTOP-AJ1S2TF 192.168.20.191 root update
INSERT INTO device_alarm (did, `date`, dsm) VALUES('4044383', '20220222', 0x3a000a043078313012043078303220422945b8c9a832303f4031832f4ca60a685e40389ac7d2900642120a0e33303334333133313336333233301001),('4050503', '20220222', 0x38000a043078313012043078303229342db1321a493f4031ca4e3fa88b685e4038a1c7d2900642120a0e33303334333133323331333633371001),('2000023', '20220222', 0x3a000a0430783034120430783031202f29e08618af79fd36403159ddea39e9695c4038a5c7d2900642120a0e33303332333333313333333433351005),('4026821', '20220222', 0x38000a04307831301204307830322982aca7565f293f40316347e350bf725e40388cc7d2900642120a0e34313432353934413337333833331001),('4051611', '20220222', 0x3a000a0430783130120430783032201229377007ea94473f403113d38558fd545e403891c7d2900642120a0e33303334333133313339333633351001),('6493492', '20220222', 0x38000a043078303412043078303220432939d4efc2d65e4040317e54c37e4f5e5c40388ec7d29006421
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 682 page no 31 n bits 112 index PRIMARY of table `httpserver`.`device_alarm` /* `p20220223` */ trx id 3902837 lock_mode X locks rec but not gap waiting
Record lock, heap no 42 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
0: len 11; hex 3430373336373431363336; asc 4073674;;
1: len 3; hex 8fcc56; asc V;;
2: len 6; hex 0000003b8d76; asc ; v;;
3: len 7; hex 5500000bba09b8; asc U ;;
4: len 30; hex 46000a04307830321204307830312a0430783031320430783030403149d1; asc F 0x02 0x01* 0x012 0x00#1I ; (total 576 bytes);
5: len 30; hex 38000a043078313012043078303229fe7bf0daa5e13e403124d1cb289672; asc 8 0x10 0x02) { >#1$ ( r; (total 412 bytes);
6: SQL NULL;
*** (2) TRANSACTION:
TRANSACTION 3902838, ACTIVE 1 sec inserting
mysql tables in use 1, locked 1
36 lock struct(s), heap size 3296, 39 row lock(s), undo log entries 48
MySQL thread id 85931, OS thread handle 8108, query id 34130125 DESKTOP-AJ1S2TF 192.168.20.191 root update
INSERT INTO device_alarm (did, `date`, adas) VALUES('1810534', '20220222', 0x46000a04307830321204307830322a0430783032320430783030404349a2410a9e42aa424051a2410a9e42aa42405895c7d2900662120a0e33353333333433303338333633381005),('2000041', '20220222', 0x46000a04307830321204307830312a04307830323204307830304020491920d1048a343f40511920d1048a343f40589ac7d2900662120a0e33303334333133313334333333391005),('1800684', '20220222', 0x48000a0430783032120430783031200b2a0430783031320430783030402e498bfcfa2136b24240518bfcfa2136b2424058a5c7d2900662120a0e33363338333433393336333133381005),('1030014', '20220222', 0x48000a043078303112043078303120062a0430783030320430783030402c4945b8c9a832ac38405145b8c9a832ac38405892c7d2900662120a0e33303331333433303333333433311005),('2000024', '20220222', 0x46000a04307830321204307830312a0430783032320430783030401f49284696ccb100374051284696ccb10037405897c7d2900662120a0e33303332333
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 682 page no 31 n bits 112 index PRIMARY of table `httpserver`.`device_alarm` /* `p20220223` */ trx id 3902838 lock_mode X locks rec but not gap
Record lock, heap no 42 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
0: len 11; hex 3430373336373431363336; asc 4073674;;
1: len 3; hex 8fcc56; asc V;;
2: len 6; hex 0000003b8d76; asc ; v;;
3: len 7; hex 5500000bba09b8; asc U ;;
4: len 30; hex 46000a04307830321204307830312a0430783031320430783030403149d1; asc F 0x02 0x01* 0x012 0x00#1I ; (total 576 bytes);
5: len 30; hex 38000a043078313012043078303229fe7bf0daa5e13e403124d1cb289672; asc 8 0x10 0x02) { >#1$ ( r; (total 412 bytes);
6: SQL NULL;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 682 page no 136 n bits 120 index PRIMARY of table `httpserver`.`device_alarm` /* `p20220223` */ trx id 3902838 lock_mode X locks rec but not gap waiting
Record lock, heap no 50 PHYSICAL RECORD: n_fields 7; compact format; info bits 0
0: len 11; hex 3138373030383530303738; asc 1870085;;
1: len 3; hex 8fcc56; asc V;;
2: len 6; hex 0000003b8d75; asc ; u;;
3: len 7; hex 540000223f2ba1; asc T "?+ ;;
4: len 30; hex 46000a04307830321204307830312a0430783032320430783030402f4983; asc F 0x02 0x01* 0x022 0x00#/I ; (total 360 bytes);
5: len 30; hex 3a000a04307830341204307830312027292ae109bdfe0e4340317a8b87f7; asc : 0x04 0x01 ')* C#1z ; (total 602 bytes);
6: SQL NULL;
*** WE ROLL BACK TRANSACTION (1)
The lock is lock_mode X locks rec but not gap, it's too strange for me to undertand it. Why did the dead lock happen?

MySQL 5.6.26 high concurrency dead lock

Table structure:
CREATE TABLE `extend_0` (
`id` bigint(20) NOT NULL,
`code` varchar(30) NOT NULL,
`data_key` varchar(50) NOT NULL,
`data_value` varchar(200) NOT NULL,
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`yn` tinyint(3) NOT NULL DEFAULT '1',
PRIMARY KEY (`id`,`create_time`),
UNIQUE KEY `idx_unq_code_data_key` (`code`,`data_key`,`create_time`) USING BTREE,
KEY `idx_code` (`code`) USING BTREE
) ENGINE=InnoDB;
When two transactions at the same time delete and insert the same data, sometimes a deadlock happened. The tx_isolation is RR.
For example:
DELETE FROM extend_0 WHERE code = '00226915986' AND yn = 1;
INSERT INTO extend_0 (id, code, data_key, data_value, create_time) VALUES (1133296779049299970, '00226915986', 'consignWare', 'food', '2019-05-28 16:59:42.418'), (1133296779049299971, '00226915986', 'productType', '0001,0006', '2019-05-28 16:59:42.418');
Deadlock log:
------------------------------------------------------------------------------
2019-05-30 14:48:07 0x7fbb7872c700
*** (1) TRANSACTION:
TRANSACTION 125554670, ACTIVE 0 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 5148727, OS thread handle 140443189679872, query id 6111057236 192.168.162.16 waybill updating
DELETE FROM extend_0 WHERE code = '00226915986' AND yn = 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 77 page no 3145 n bits 360 index idx_unq_code_data_key of table `waybill_0`.`extend_0` trx id 125554670 lock_mode X waiting
Record lock, heap no 285 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 15; hex 4a4456433030323236393135393836; asc 00226915986;;
1: len 11; hex 636f6e7369676e57617265; asc consignWare;;
2: len 4; hex 5cecf87e; asc \ ~;;
3: len 8; hex 911d8ce2e1ddf000; asc ;;
*** (2) TRANSACTION:
TRANSACTION 125554668, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1136, 6 row lock(s), undo log entries 3
MySQL thread id 5148728, OS thread handle 140443156399872, query id 6111057237 192.168.162.16 waybill update
INSERT INTO extend_0 (id, code, data_key, data_value, create_time) VALUES (i-1, '00226915986', 'consignWare', 'food', '2019-05-28 16:59:42.418'), (i, '00226915986', 'productType', '0001,0006', '2019-05-28 16:59:42.418')
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 77 page no 3145 n bits 360 index idx_unq_code_data_key of table `waybill_0`.`extend_0` trx id 125554668 lock_mode X
Record lock, heap no 285 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 15; hex 4a4456433030323236393135393836; asc 00226915986;;
1: len 11; hex 636f6e7369676e57617265; asc consignWare;;
2: len 4; hex 5cecf87e; asc \ ~;;
3: len 8; hex 911d8ce2e1ddf000; asc ;;
Record lock, heap no 287 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 15; hex 4a4456433030323236393135393836; asc 00226915986;;
1: len 11; hex 70726f6475637454797065; asc productType;;
2: len 4; hex 5cecf87e; asc \ ~;;
3: len 8; hex 911d8ce2e1ddf020; asc ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 77 page no 3145 n bits 360 index idx_unq_waybill_code_data_key of table `waybill_0`.`extend_0` trx id 125554668 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 285 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
0: len 15; hex 4a4456433030323236393135393836; asc JDVC00226915986;;
1: len 11; hex 636f6e7369676e57617265; asc consignWare;;
2: len 4; hex 5cecf87e; asc \ ~;;
3: len 8; hex 911d8ce2e1ddf000; asc ;;
*** WE ROLL BACK TRANSACTION (1)
------------------------------------------------------------------------------
The transaction2 has lock_mode X already. Why does "lock_mode X locks gap before rec insert intention waiting" happen?
But when we execute the transactions one by one a deadlock does not happen. For example:
step1: tx1 begin; delete.....;
step2: tx2 begin; delete.....;
step3: tx1 insert....;
step4: tx2 insert....;
step5: tx1 commit;
The deadlock happens only when there is high concurrency; the deadlock looks to be caused by the concurrency of tx1's delete and tx2's insert.
What lock does transaction 1 hold?Why transaction 2 is waiting for transaction 1?
Plan A:
Live with it. That is, check for errors, see that there is a deadlock, and restart the transaction. You should have this code even if you go with Plan B.
Plan B:
BEGIN;
SELECT ... WHERE code = '00226915986' AND yn = 1 FOR UPDATE;
DELETE ...
INSERT ...
COMMIT;
This should force any other connection to wait instead of deadlock.

How these transactions cause deadlock?

I've 2 types of transactions:
Type 1 includes the following Sqls:
UPDATE userdb_ingest_report SET start_time='%s', end_time='%s', is_csv_ingest=%d, success=%d, failed=%d WHERE clientid='%s' AND filename='%s' AND network_id=%d AND data_provider_id=%d;\n
or
INSERT INTO userdb_ingest_report(clientid, filename, network_id, data_provider_id, start_time, end_time, is_csv_ingest, success, failed) VALUES ('%s', '%s', %d, %d, '%s', '%s', %d, %d, %d);\n"
and
DELETE FROM userdb_ingest_report WHERE clientid<>'%s' AND filename='%s' AND network_id=%d AND data_provider_id=%d;\n
Type 2 includes the following Sqls:
UPDATE userdb_ingest_report SET start_time=LEAST(%s, start_time), end_time=GREATEST(%s, end_time), is_csv_ingest=%d, success=success+%d, failed=failed+%d WHERE clientid='%s' AND filename='%s' AND network_id='%d' AND data_provider_id='%d'"
or
INSERT INTO userdb_ingest_report(clientid, filename, network_id, data_provider_id, start_time, end_time, is_csv_ingest, success, failed) VALUES ('%s', '%s', %d, %d, '%s', '%s', %d, %d, %d);\n
There may be 1 instance of type1 and 1-6 instances of type2 running concurrently. Sometimes I'll get the deadlock failure:
Update table userdb_ingest_report error. Sql:UPDATE userdb_ingest_report SET start_time=LEAST(20170622134845, start_time), end_time=GREATEST(20170622134846, end_time), is_csv_ingest=1, success=success+184, failed=failed+0 WHERE clientid='clienta' AND filename='file1' AND network_id='48804' AND data_provider_id='386123', Error:Error 1213: Deadlock found when trying to get lock; try restarting transaction
or
Insert table userdb_ingest_report error. Sql:INSERT INTO userdb_ingest_report(clientid, filename, network_id, data_provider_id, start_time, end_time, is_csv_ingest, success, failed) VALUES ('clientb', 'fileb', 385316, 385316, '20170622140908', '20170622140922', 1, 372521, 0); , Error:Error 1213: Deadlock found when trying to get lock; try restarting transaction
and this is the schema of this table:
CREATE TABLE `userdb_ingest_report` (
`filename` varchar(255) NOT NULL,
`network_id` bigint(20) NOT NULL,
`data_provider_id` bigint(20) NOT NULL,
`start_time` datetime NOT NULL,
`end_time` datetime NOT NULL,
`is_csv_ingest` smallint(1) NOT NULL,
`success` bigint(20) DEFAULT '0',
`failed` bigint(20) DEFAULT '0',
`clientid` char(30) DEFAULT '',
KEY `network_data_provider_clientid_idx` (`network_id`,`data_provider_id`,`clientid`,`filename`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
When I use show innodb status in mysql, I got the following messages about the last deadlock information:
------------------------
LATEST DETECTED DEADLOCK
------------------------
170622 21:15:22
*** (1) TRANSACTION:
TRANSACTION 3F427F4B, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 30 lock struct(s), heap size 6960, 41 row lock(s), undo log entries 14
MySQL thread id 43053224, OS thread handle 0x2b8f80ffe940, query id 1158507552 10.1.10.42 backend_new update
INSERT INTO userdb_ingest_report(clientid, filename, network_id, data_provider_id, start_time, end_time, is_csv_ingest, success, failed) VALUES ('auingest03.fwmrm.net_1', '/mnt/sftponly/381963/files/audience/ingest/pending/visitor_attr_381963_20170622145737.csv.gz', 0, 381963, '20170622211520', '20170622211522', 1, 18203, 0)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1026 page no 711706 n bits 176 index `network_data_provider_clientid_idx` of table `fwmrm_stats`.`userdb_ingest_report` trx id 3F427F4B lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 16 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 8; hex 8000000000000000; asc ;;
1: len 8; hex 800000000005d457; asc W;;
2: len 30; hex 202020202020202020202020202020202020202020202020202020202020; asc ;;
3: len 30; hex 2f6d6e742f736674706f6e6c792f3338323033392f66696c65732f617564; asc /mnt/sftponly/382039/files/aud; (total 92 bytes);
4: len 6; hex 00000c420d62; asc B b;;
*** (2) TRANSACTION:
TRANSACTION 3F427F4C, ACTIVE 0 sec inserting, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
28 lock struct(s), heap size 6960, 38 row lock(s), undo log entries 13
MySQL thread id 43053207, OS thread handle 0x2b8f80bee940, query id 1158507553 10.1.10.41 backend_new update
INSERT INTO userdb_ingest_report(clientid, filename, network_id, data_provider_id, start_time, end_time, is_csv_ingest, success, failed) VALUES ('auingest02.fwmrm.net_1', '/mnt/sftponly/381963/files/audience/ingest/pending/visitor_attr_381963_20170622145737.csv.gz', 0, 381963, '20170622211520', '20170622211522', 1, 36103, 0)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1026 page no 711706 n bits 176 index `network_data_provider_clientid_idx` of table `fwmrm_stats`.`userdb_ingest_report` trx id 3F427F4C lock_mode X locks gap before rec
Record lock, heap no 16 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 8; hex 8000000000000000; asc ;;
1: len 8; hex 800000000005d457; asc W;;
2: len 30; hex 202020202020202020202020202020202020202020202020202020202020; asc ;;
3: len 30; hex 2f6d6e742f736674706f6e6c792f3338323033392f66696c65732f617564; asc /mnt/sftponly/382039/files/aud; (total 92 bytes);
4: len 6; hex 00000c420d62; asc B b;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1026 page no 711706 n bits 176 index `network_data_provider_clientid_idx` of table `fwmrm_stats`.`userdb_ingest_report` trx id 3F427F4C lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 16 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 8; hex 8000000000000000; asc ;;
1: len 8; hex 800000000005d457; asc W;;
2: len 30; hex 202020202020202020202020202020202020202020202020202020202020; asc ;;
3: len 30; hex 2f6d6e742f736674706f6e6c792f3338323033392f66696c65732f617564; asc /mnt/sftponly/382039/files/aud; (total 92 bytes);
4: len 6; hex 00000c420d62; asc B b;;
so how would this happen, and how can I solve this deadlock?

MySQL updates getting stuck

I have a Mediacore-based website that is getting stuck due to an update query. Those update queries are running all the time, but sometimes (I believe, during high traffic hours), one of those updates just becomes stuck, locking all other queries:
245 mediacore_user localhost mediacore Query 36 Locked UPDATE media SET modified_on='2011-12-21 09:42:58', views=(media.views + 1) WHERE media.id = 1048
246 mediacore_user localhost mediacore Query 36 Locked UPDATE media SET modified_on='2011-12-21 09:42:58', views=(media.views + 1) WHERE media.id = 1048
248 mediacore_user localhost mediacore Query 36 Updating UPDATE media SET modified_on='2011-12-21 09:42:58', views=(media.views + 1) WHERE media.id = 1048
249 mediacore_user localhost mediacore Query 36 Locked UPDATE media SET modified_on='2011-12-21 09:42:58', views=(media.views + 1) WHERE media.id = 1048
253 mediacore_user localhost mediacore Query 36 Locked UPDATE media SET modified_on='2011-12-21 09:42:58', views=(media.views + 1) WHERE media.id = 1048
258 mediacore_user localhost mediacore Query 30 Locked UPDATE media SET modified_on='2011-12-21 09:43:04', views=(media.views + 1) WHERE media.id = 416
268 mediacore_user localhost mediacore Query 3 Locked UPDATE media SET modified_on='2011-12-21 09:43:31', views=(media.views + 1) WHERE media.id = 1048
269 mediacore_user localhost mediacore Query 3 Locked UPDATE media SET modified_on='2011-12-21 09:43:31', views=(media.views + 1) WHERE media.id = 1048
270 mediacore_user localhost mediacore Query 3 Locked UPDATE media SET modified_on='2011-12-21 09:43:31', views=(media.views + 1) WHERE media.id = 1048
271 mediacore_user localhost mediacore Query 3 Locked UPDATE media SET modified_on='2011-12-21 09:43:31', views=(media.views + 1) WHERE media.id = 1048
272 mediacore_user localhost mediacore Query 1 Locked UPDATE media SET modified_on='2011-12-21 09:43:33', views=(media.views + 1) WHERE media.id = 1048
If I kill the "Updating" connection, another one gets stuck, and so on, until there are only about 3 queries left locked.
Any ideas?
Media table:
CREATE TABLE `media` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`type` varchar(8) DEFAULT NULL,
`slug` varchar(50) NOT NULL,
`podcast_id` int(11) DEFAULT NULL,
`reviewed` tinyint(1) NOT NULL,
`encoded` tinyint(1) NOT NULL,
`publishable` tinyint(1) NOT NULL,
`created_on` datetime NOT NULL,
`modified_on` datetime NOT NULL,
`publish_on` datetime DEFAULT NULL,
`publish_until` datetime DEFAULT NULL,
`title` varchar(255) NOT NULL,
`subtitle` varchar(255) DEFAULT NULL,
`description` text,
`description_plain` text,
`notes` text,
`duration` int(11) NOT NULL,
`views` int(11) NOT NULL,
`likes` int(11) NOT NULL,
`popularity_points` int(11) NOT NULL,
`author_name` varchar(50) NOT NULL,
`author_email` varchar(255) NOT NULL,
`dislikes` int(11) NOT NULL,
`popularity_likes` int(11) NOT NULL,
`popularity_dislikes` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `slug` (`slug`),
KEY `podcast_id` (`podcast_id`),
CONSTRAINT `media_ibfk_1` FOREIGN KEY (`podcast_id`) REFERENCES `podcasts` (`id`) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=1049 DEFAULT CHARSET=utf8
INNODB Status after the problem happened:
=====================================
111221 12:12:09 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 6 seconds
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 78, signal count 78
Mutex spin waits 0, rounds 453, OS waits 17
RW-shared spins 122, OS waits 61; RW-excl spins 0, OS waits 0
------------
TRANSACTIONS
------------
Trx id counter 0 1115749
Purge done for trx's n:o < 0 1115735 undo n:o < 0 0
History list length 13
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0 1115747, not started, process no 15360, OS thread id 140486827099904
MySQL thread id 111, query id 11647 localhost mediacore_user
---TRANSACTION 0 0, not started, process no 15360, OS thread id 140486827898624
MySQL thread id 106, query id 11651 localhost root
show innodb status
---TRANSACTION 0 1115709, not started, process no 15360, OS thread id 140486826567424
MySQL thread id 103, query id 10874 localhost mediacore_user
---TRANSACTION 0 1115731, not started, process no 15360, OS thread id 140486792349440
MySQL thread id 102, query id 11517 localhost mediacore_user
---TRANSACTION 0 1115668, not started, process no 15360, OS thread id 140486792881920
MySQL thread id 101, query id 10067 localhost 127.0.0.1 a7user
---TRANSACTION 0 1115737, not started, process no 15360, OS thread id 140486791816960
MySQL thread id 95, query id 11578 localhost mediacore_user
---TRANSACTION 0 1115738, not started, process no 15360, OS thread id 140486827366144
MySQL thread id 87, query id 11577 localhost mediacore_user
---TRANSACTION 0 1115744, not started, process no 15360, OS thread id 140486827632384
MySQL thread id 61, query id 11606 localhost mediacore_user
---TRANSACTION 0 1115746, not started, process no 15360, OS thread id 140486826301184
MySQL thread id 22, query id 11633 localhost mediacore_user
---TRANSACTION 0 1115748, ACTIVE 1 sec, process no 15360, OS thread id 140486826833664
mysql tables in use 1, locked 1
MySQL thread id 55, query id 11650 localhost mediacore_user Table lock
UPDATE media SET modified_on='2011-12-21 12:12:08', dislikes=10 WHERE media.id = 572
Trx read view will not see trx with id >= 0 1115749, sees < 0 1115740
---TRANSACTION 0 1115743, ACTIVE 14 sec, process no 15360, OS thread id 140486826034944
mysql tables in use 1, locked 1
MySQL thread id 23, query id 11601 localhost mediacore_user Table lock
UPDATE media SET modified_on='2011-12-21 12:11:55', views=(media.views + 1) WHERE media.id = 1048
Trx read view will not see trx with id >= 0 1115744, sees < 0 1115740
---TRANSACTION 0 1115742, ACTIVE 14 sec, process no 15360, OS thread id 140486825502464
mysql tables in use 1, locked 1
MySQL thread id 90, query id 11599 localhost mediacore_user Table lock
UPDATE media SET modified_on='2011-12-21 12:11:55', views=(media.views + 1) WHERE media.id = 1048
Trx read view will not see trx with id >= 0 1115743, sees < 0 1115740
---TRANSACTION 0 1115741, ACTIVE 14 sec, process no 15360, OS thread id 140486825768704 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 368, 1 row lock(s)
MySQL thread id 73, query id 11596 localhost mediacore_user Updating
UPDATE media SET modified_on='2011-12-21 12:11:55', views=(media.views + 1) WHERE media.id = 1048
Trx read view will not see trx with id >= 0 1115742, sees < 0 1115740
------- TRX HAS BEEN WAITING 14 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 1025 n bits 88 index `PRIMARY` of table `mediacore`.`media` trx id 0 1115741 lock_mode X locks rec but not gap waiting
Record lock, heap no 20 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
0: len 4; hex 80000418; asc ;; 1: len 6; hex 00000011065c; asc \;; 2: len 7; hex 00000003c20d5b; asc [;; 3: len 5; hex 766964656f; asc video;; 4: len 30; hex 617273656c696f2d7061746f2d64652d63617276616c686f2d686f6d656e; asc arselio-pato-de-carvalho-homen;...(truncated); 5: len 4; hex 80000013; asc ;; 6: len 1; hex 81; asc ;; 7: len 1; hex 81; asc ;; 8: len 1; hex 81; asc ;; 9: len 8; hex 8000124a82217b0b; asc J !{ ;; 10: len 8; hex 8000124a8230e083; asc J 0 ;; 11: len 8; hex 8000124a82220ef0; asc J " ;; 12: SQL NULL; 13: len 30; hex 417273c3a96c696f205061746f2064652043617276616c686f20686f6d65; asc Ars lio Pato de Carvalho home;...(truncated); 14: SQL NULL; 15: len 30; hex 3c703e43656e74726f206465204e6575726f6369c3aa6e63696173206520; asc <p>Centro de Neuroci ncias e ;...(truncated); 16: len 30; hex 43656e74726f206465204e6575726f6369c3aa6e6369617320652042696f; asc Centro de Neuroci ncias e Bio;...(truncated); 17: SQL NULL; 18: len 4; hex 80000000; asc ;; 19: len 4; hex 80000099; asc ;; 20: len 4; hex 80000000; asc ;; 21: len 4; hex 80000000; asc ;; 22: len 3; hex 554356; asc UCV;; 23: len 9; hex 7563764075632e7074; asc ucv#uc.pt;; 24: len 4; hex 80000000; asc ;; 25: len 4; hex 80000000; asc ;; 26: len 4; hex 80000000; asc ;;
------------------
---TRANSACTION 0 1115740, ACTIVE 14 sec, process no 15360, OS thread id 140486792083200
2 lock struct(s), heap size 368, 1 row lock(s), undo log entries 1
MySQL thread id 97, query id 11597 localhost mediacore_user Table lock
SELECT 1
FROM media_fulltext
LIMIT 1
Trx read view will not see trx with id >= 0 1115741, sees < 0 1115741
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (write thread)
Pending normal aio reads: 0, aio writes: 0,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
187 OS file reads, 469 OS file writes, 298 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2,
0 inserts, 0 merged recs, 0 merges
Hash table size 2212699, node heap has 9 buffer(s)
0.17 hash searches/s, 0.17 non-hash searches/s
---
LOG
---
Log sequence number 0 148655397
Log flushed up to 0 148655397
Last checkpoint at 0 148655397
0 pending log writes, 0 pending chkp writes
177 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 1225697720; in additional pool allocated 11846912
Dictionary memory allocated 203840
Buffer pool size 65536
Free buffers 65299
Database pages 228
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages read 225, created 3, written 259
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
6 read views open inside InnoDB
Main thread process no. 15360, id 140486801540864, state: sleeping
Number of rows inserted 13, updated 85, deleted 2, read 281971
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.17 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
EDIT: Somehow, some of the updates are not unlocking the table after they commit. I watched the queries for quite some time and saw that after 50 seconds, the lock is freed and one update is executed. I've changed the innodb_lock_wait_timeout to 5 and I saw the same thing, only with intervals of 5 seconds instead of 50. But once it gets only a few updates left locked, they're all executed instantaneously... it's a very strange behavior...
A bit late but I'd like to add some more information: From my observation this happens if you have the full-text index enabled. In that case there seems to be a bad interaction in MySQL involving InnoDB (media table) and MyISAM (full-text index) locking.
I never saw the issue if MediaCore's full-text triggers were not installed.
I think it is because of the large number of queries at a time. Try using mysql index with your fields. It will speed up the performance.