在MySQL InnoDB中获取后续查询的锁定

Question

I am trying to investigate deadlock issues in my application. My table looks something like this.

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

• A Service(multiple threads) issues insert statements on this table.

• Multiple clients issue following queries in order in two separate transactions.

  update requests set process_id='" + hostName + "' where status='Received' and process_id is null order by req_id asc limit 100"

  select * from requests where process_id='"+ hostName + "' where status='Received';

  update requests set status='Processing' where req_id='xyz'

Req_id in 3rd query is list of req ids retrieved from 2nd query.

But on client side some times, we see following exception.

Deadlock found when trying to get lock; try restarting transaction
org.hibernate.exception.LockAcquisitionException: could not execute native bulk manipulation query

Can above queries result in deadlock, if yes how can we resolve it? Also is there a way to reproduce this issue locally?

Here is output of '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

Answer 1

Some background

MySQL takes write locks out on an UPDATE statement the first time it visits the records. It doesn't elevate locks from read to write. It locks based on the current index .

In your UPDATE statement, MySQL is most likely using the index on the status column, so MySQL locks every record where status = 'Received'.

Note that any time you lock more than a single unique record (using a unique index, such as the primary key), you are locking a gap (or range).

An update against a single record still takes a next-key lock, which means it locks the selected record and the next one in the index.

Two UPDATES on the same index (both with a next-key) lock won't conflict (they'll always be locked in the same order). However, since your range lock is against a secondary index, it could deadlock.

Here's the scenario that is occurring :

Let's say you have two records with req_ids 1 and 2.

Your first transaction updates against the status index and needs to lock both records 1 and 2, but it's not guaranteed to be in the same order as the primary key, so it locks record 2, and is about to lock record 1.

Your second transaction locks on the req_id index, and needs to update record 1. It immediately locks record 1, but it also needs to perform a next-key lock on record 2.

The two transactions are now deadlocked. Transaction 1 needs to lock record 1, and transaction 2 needs to lock record 2.

The solution

To avoid deadlocks in your case, you could explicitly lock the entire table using LOCK TABLES , or simply retry a transaction if it fails. MySQL will detect the deadlock, and one of your transactions will get rolled back.

MySQL does provide some instructions to help you cope with deadlocks .

It also seems like you should delete the redundant key pk_idx_requests, since your primary key already includes that column.

Answer 2

Yes, these queries could result in a deadlock. In fact, as mentioned in the MySQL doco, you can get deadlocks even in the case of transactions that just insert or delete a single row. See How to Cope with Deadlocks

You could try indexing process_id to try to speed up the queries/updates.