10

次の状況の場合、mysqlのバグ？

Mysqlバージョン：mysql.x86_64 5.0.77-4.el5_4.1

カーネル：Linux box2 2.6.18-128.el5＃1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU / Linux

------------------------
LATEST DETECTED DEADLOCK
------------------------
100125  4:24:41
*** (1) TRANSACTION:
TRANSACTION 0 210510625, ACTIVE 155 sec, process no 28125, OS thread id 1243162944 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1216, undo log entries 1
MySQL thread id 162928579, query id 527252744 box22 172.16.11.105 user updating
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210510625 lock_mode X locks rec but not gap waiting
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 8; hex 0000000027ec235e; asc     ' #^;; 1: len 4; hex 0000002d; asc    -;; 2: len 4; hex 00000041; asc    A;; 3: len 6; hex 00000b561243; asc    V C;; 4: len 7; hex 80000040070110; asc    @   ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc  Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc     ;; 9: len 1; hex 80; asc  ;;

*** (2) TRANSACTION:
TRANSACTION 0 210505911, ACTIVE 555 sec, process no 28125, OS thread id 1184323904 starting index read, thread declared inside InnoDB 500
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1216, undo log entries 1
MySQL thread id 162924258, query id 527252762 box22 172.16.11.105 user updating
delete from user_grid_items where user_id = 669786974 and START_X = 45 and START_Y = 65
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock mode S locks rec but not gap
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 8; hex 0000000027ec235e; asc     ' #^;; 1: len 4; hex 0000002d; asc    -;; 2: len 4; hex 00000041; asc    A;; 3: len 6; hex 00000b561243; asc    V C;; 4: len 7; hex 80000040070110; asc    @   ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc  Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc     ;; 9: len 1; hex 80; asc  ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 61372 n bits 328 index `PRIMARY` of table `gamesutra_beta/user_grid_items` trx id 0 210505911 lock_mode X locks rec but not gap waiting
Record lock, heap no 127 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
0: len 8; hex 0000000027ec235e; asc     ' #^;; 1: len 4; hex 0000002d; asc    -;; 2: len 4; hex 00000041; asc    A;; 3: len 6; hex 00000b561243; asc    V C;; 4: len 7; hex 80000040070110; asc    @   ;; 5: len 23; hex 474949445f414e494d414c535f53515549445f50494e4b; asc GIID_ANIMALS_SQUID_PINK;; 6: len 4; hex cb59f060; asc  Y `;; 7: len 4; hex 4b59f060; asc KY `;; 8: len 4; hex 80000000; asc     ;; 9: len 1; hex 80; asc  ;;

*** WE ROLL BACK TRANSACTION (2)
------------
4

3 に答える 3

6

SHOW ENGINE INNODB STATUS は、トランザクション内の現在のステートメントのみを表示するため、解読が難しい場合があります。実際に保持されているロックを取得した可能性がある同じトランザクションで以前に発生したステートメントは表示されません。

あなたの場合、トランザクション 2 の前のステートメントは、問題の行の共有ロックを取得しました。

次に、トランザクション 1 は同じ行で排他ロックを取得しようとし、共有ロックが削除されるのを喜んで待っています。

次に、別のステートメントで、トランザクション 2 が同じ行の排他ロックを取得しようとしました。古典的なデッドロック。どちらのトランザクションも終了できません。

このようなデッドロックを回避するための 1 つの解決策はSELECT FOR UPDATE、共有ロックを取得するステートメントの前に、ステートメントを使用してトランザクション 2 の行の排他ロックを取得することです。

于 2012-06-28T13:00:39.967 に答える
1

私はずっと前に何かを読みましたが、結果としてあなたが実行しているものであるかどうかはわかりません...現在のトランザクションと競合しているもののトランザクションのコードを見ずに。

トランザクションを処理するときは、常に同じ順序でロックを行うようにする必要があります...注文/注文詳細/支払いシステムの場合、ここに例としてリストされている順序ですべての同様のアクティビティを実行します。「注文明細/注文」の順にトランザクションを試行する別のプロセスがある場合、デッドロックが発生する可能性があります。

1 つのトランザクションでは、最初に注文番号がロックされ、次に注文の詳細が処理されます。他のトランザクションは、最初に注文の詳細をロックし、次に注文ヘッダーを取得しようとします。

HTH

于 2012-02-13T13:07:30.013 に答える
-4

SHOW ENGINE INNODB STATUSを使用して、最新のデッドロックの原因を特定します。これは、アプリケーションを調整してデッドロックを回避するのに役立ちます。

デッドロックが原因でトランザクションが失敗した場合は、常にトランザクションを再発行する準備をしてください。デッドロックは危険ではありません。もう一度やり直してください。

于 2011-08-25T07:54:14.357 に答える