1

アプリケーションのデッドロックの問題を調査しようとしています。私のテーブルはこんな感じです。

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
  • サービス（複数のスレッド）は、このテーブルに挿入ステートメントを発行します。

  • 複数のクライアントが、2つの別々のトランザクションで順番に次のクエリを発行します。

    更新要求はprocess_id='"+hostName +"'を設定します。ここでstatus='Received'であり、process_idはreq_id asclimit100によるnullオーダーです。

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

    更新要求はstatus='Processing'を設定します。ここでreq_id='xyz'

3番目のクエリのReq_idは、2番目のクエリから取得した要求IDのリストです。

ただし、クライアント側では、次の例外が発生する場合があります。

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

上記のクエリでデッドロックが発生する可能性がありますか？はいの場合、どうすれば解決できますか？また、この問題をローカルで再現する方法はありますか？

これが「showinnodbstatus」の出力です

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
4

2 に答える 2

3

いくつかの背景

MySQLは、レコードに初めてアクセスしたときに、UPDATEステートメントの書き込みロックを解除します。ロックを読み取りから書き込みに昇格させることはありません。現在のインデックスに基づいてロックします。

UPDATEステートメントでは、MySQLはステータス列のインデックスを使用している可能性が高いため、MySQLはstatus='Received'であるすべてのレコードをロックします。

（主キーなどの一意のインデックスを使用して）複数の一意のレコードをロックするときは常に、ギャップ（または範囲）をロックしていることに注意してください。

単一のレコードに対する更新でも、次のキーのロックが適用されます。つまり、選択したレコードとインデックス内の次のレコードがロックされます。

同じインデックス（両方とも次のキーを持つ）ロックの2つのUPDATEは競合しません（常に同じ順序でロックされます）。ただし、範囲ロックはセカンダリインデックスに対して行われるため、デッドロックが発生する可能性があります。

発生しているシナリオは次のとおりです。

req_ids1と2の2つのレコードがあるとします。

最初のトランザクションはステータスインデックスに対して更新され、レコード1と2の両方をロックする必要がありますが、主キーと同じ順序であることが保証されていないため、レコード2をロックし、レコード1をロックしようとしています。

2番目のトランザクションはreq_idインデックスをロックし、レコード1を更新する必要があります。すぐにレコード1をロックしますが、レコード2で次のキーのロックも実行する必要があります。

2つのトランザクションがデッドロックされました。トランザクション1はレコード1をロックする必要があり、トランザクション2はレコード2をロックする必要があります。

ソリューション

この場合のデッドロックを回避するには、を使用してテーブル全体を明示的にロックするLOCK TABLESか、失敗した場合は単にトランザクションを再試行します。MySQLはデッドロックを検出し、トランザクションの1つがロールバックされます。

MySQLは、デッドロックに対処するのに役立ついくつかの指示を提供します。

また、主キーにはすでにその列が含まれているため、冗長キーpk_idx_requestsを削除する必要があるようです。

于 2012-05-07T20:49:00.300 に答える
0

はい、これらのクエリはデッドロックを引き起こす可能性があります。実際、MySQLドキュメントで説明されているように、単一の行を挿入または削除するだけのトランザクションの場合でも、デッドロックが発生する可能性があります。デッドロックに対処する方法を参照してください

process_idにインデックスを付けて、クエリ/更新を高速化することができます。

于 2012-05-07T20:20:16.207 に答える