我正在尝试调查我的应用程序中的死锁问题。我的表看起来像这样。
CREATE TABLE `requests` (
`req_id` bigint(20) NOT NULL auto_increment,
`status` varchar(255) default NULL,
`process_id` varchar(200) default NULL,
PRIMARY KEY (`req_id`),
KEY `status_idx` USING BTREE (`status`),
KEY `pk_idx_requests` USING BTREE (`req_id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8
多个客户端在两个单独的事务中按顺序发出以下查询。
更新请求设置process_id ='“+ hostName +”'其中status ='已接收'且process_id为空订单req_id asc limit 100“
select * from requests where process_id ='“+ hostName +”'where status ='Received';
更新请求设置状态='处理',其中req_id ='xyz'
第三个查询中的Req_id是从第二个查询中检索到的请求列表。
但有时在客户端,我们会看到以下异常。
Deadlock found when trying to get lock; try restarting transaction
org.hibernate.exception.LockAcquisitionException: could not execute native bulk manipulation query
以上查询是否会导致死锁,如果是,我们如何解决?还有一种方法可以在本地重现这个问题吗?
这是'show innodb status'的输出
LATEST DETECTED DEADLOCK
------------------------
120507 6:03:21
*** (1) TRANSACTION:
TRANSACTION 115627, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1248, 25 row lock(s)
MySQL thread id 432399, OS thread handle 0x419e4940, query id 4111695 * * * Searching rows for update
update requests set process_id='**' where status='Received' and process_id is null order by req_id asc limit 100
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 4 page no 3797 n bits 136 index `PRIMARY` of table `db`.`requests` trx id 115627 lock_mode X locks rec but not gap waiting
Record lock, heap no 67 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
*** (2) TRANSACTION:
TRANSACTION 115626, ACTIVE 1 sec updating or deleting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1248, 2 row lock(s), undo log entries 1
MySQL thread id 432403, OS thread handle 0x41c19940, query id 4111694 * * * Updating
update requests set status='Processing', process_id='**' where req_id=3026296
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 4 page no 3797 n bits 136 index `PRIMARY` of table `db`.`requests` trx id 115626 lock_mode X locks rec but not gap
Record lock, heap no 67 PHYSICAL RECORD: n_fields 27; compact format; info bits 0
答案 0 :(得分:3)
一些背景
MySQL首次访问记录时会在UPDATE语句中取出写锁定。它不会将锁从读取提升到写入。它locks based on the current index。
在你的UPDATE语句中,MySQL最有可能使用status列上的索引,因此MySQL会锁定status ='Received'的每条记录。
请注意,只要您锁定多个唯一记录(使用唯一索引,例如主键),就会锁定间隙(或范围)。
针对单个记录的更新仍然采用下一键锁定,这意味着它会锁定所选记录和索引中的下一个记录。
同一索引上的两个UPDATES(都带有下一个键)锁定不会发生冲突(它们将始终以相同的顺序锁定)。但是,由于您的范围锁定是针对二级索引,因此可能会死锁。
以下是正在发生的方案:
假设你有两条req_ids 1和2的记录。
您的第一个事务更新状态索引并需要锁定记录1和2,但不保证与主键的顺序相同,因此它会锁定记录2,并且即将锁定记录1。
您的第二个事务锁定了req_id索引,需要更新记录1.它会立即锁定记录1,但它还需要在记录2上执行下一键锁定。
这两笔交易现已陷入僵局。事务1需要锁定记录1,事务2需要锁定记录2。
解决方案
为避免出现死锁,您可以使用LOCK TABLES
显式锁定整个表,或者只是在失败时重试事务。 MySQL将检测死锁,你的一个事务将被回滚。
MySQL确实向help you cope with deadlocks提供了一些说明。
您似乎应该删除冗余密钥pk_idx_requests,因为您的主密钥已包含该列。
答案 1 :(得分:0)
是的,这些查询可能会导致死锁。实际上,正如MySQL doco中所提到的,即使在只插入或删除单行的事务中,也可能出现死锁。见How to Cope with Deadlocks
您可以尝试索引process_id以尝试加快查询/更新。