0

私は、時折現れる InnoDB のデッドロックに頭を悩ませようとしています。

------------------------
LATEST DETECTED DEADLOCK
------------------------
110511 10:45:59
*** (1) TRANSACTION:
TRANSACTION 0 959459752, ACTIVE 0 sec, process no 24148, OS thread id 2958613424 starting index read
mysql tables in use 16, locked 16
LOCK WAIT 2 lock struct(s), heap size 320
MySQL thread id 13029007, query id 85826239 localhost andrew updating
DELETE FROM `clients_permission_assignments` WHERE permission_assignment_id = 3761 AND client_id IN (52621)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 1490959 n bits 864 index `unique_index` of table `test/clients_permission_assignments` trx id 0 959459752 lock_mode X waiting
Record lock, heap no 202 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
 0: len 4; hex 8000cd8d; asc     ;; 1: len 4; hex 80000eb1; asc     ;; 2: len 6; hex 0000006b7d5c; asc    k}\;;

*** (2) TRANSACTION:
TRANSACTION 0 959459751, ACTIVE 0 sec, process no 24148, OS thread id 1996331952 fetching rows, thread declared inside InnoDB 354
mysql tables in use 16, locked 16
20 lock struct(s), heap size 2496, undo log entries 1
MySQL thread id 13019094, query id 85826237 localhost andrew Copying to tmp table
CREATE TEMPORARY TABLE tmp_tests_people_cleanup_table (SELECT unit_code FROM (
              SELECT u.unit_code, COUNT(u.unit_code) AS cnt FROM staging.client_test_utilization u
              LEFT JOIN permission_assignments pa ON pa.person_id =
                  (SELECT person_id FROM permission_assignments pa WHERE pa.id = OLD.permission_assignment_id)
              LEFT JOIN permissions p ON pa.permission_id = p.id
              LEFT JOIN clients_permission_assignments cpa ON cpa.permission_assignment_id = pa.id
              LEFT JOIN clients c ON c.id = cpa.client_id
              LEFT JOIN staging.client_test_utilization u2 ON CONCAT('C',u2.client_number) = c.number
                  AND u2.unit_code = u.unit_code
              WHERE p.label = 'Receive Test Updates'
                  AND CONCAT('C',u.client_number) = (SELECT number from clients WHERE id = OLD.client_id)
                  AND u2.id IS NULL GROUP BY u.unit_code
          ) tbl
          WHERE cnt = (SELECT COUNT(*) FROM permission_assignments pa
                      LEFT JOIN permissions p ON pa.permission_id = p.id
                      LEFT JOIN clients_permission_assignments cpa ON cpa.permission_assignment_id = pa.id
                      WHERE p.label = 'Receive Test Updates' AND pa.person_id =
                          (SELECT person_id FROM permission_assignments pa WHERE pa.id = OLD.permission_assignment_id))
              OR (SELECT COUNT(*) FROM permission_assignments pa
                      LEFT JOIN permissions p ON pa.permission_id = p.id
                      LEFT JOIN clients_permission_assignments cpa ON cpa.permission_assignment_id = pa.id
                      WHERE p.label = 'Receive Test Updates' AND pa.person_id =
                          (SELECT person_id FROM permission_assignments pa WHERE pa.id = OLD.permission_assignment_id)) = 0)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 1490959 n bits 864 index `unique_index` of table `test/clients_permission_assignments` trx id 0 959459751 lock_mode X locks rec but not gap
Record lock, heap no 202 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
 0: len 4; hex 8000cd8d; asc     ;; 1: len 4; hex 80000eb1; asc     ;; 2: len 6; hex 0000006b7d5c; asc    k}\;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 1490959 n bits 864 index `unique_index` of table `test/clients_permission_assignments` trx id 0 959459751 lock mode S waiting
Record lock, heap no 202 PHYSICAL RECORD: n_fields 3; compact format; info bits 32
 0: len 4; hex 8000cd8d; asc     ;; 1: len 4; hex 80000eb1; asc     ;; 2: len 6; hex 0000006b7d5c; asc    k}\;;

*** WE ROLL BACK TRANSACTION (1)

当時は知りませんでしたが、INSERT ... SELECT、CREATE ... SELECT は SELECT クエリ内のすべてのテーブルをロックするようです。ご覧のとおり、結合とサブクエリを含むテーブルが多数あります。ロックは共有 (S) ロックだと思っていましたが、上記のデータから、排他 (X) ロックを保持しているようです。理由がわかりません。

たぶん、誰かが CREATE ... SELECT クエリに排他的 (X) ロックがある理由を理解するのを手伝ってくれれば、このデッドロックを解決しようとすることができます。または、デッドロックについてさらに支援を得ることができるかもしれません。

ありがとうございました。

4

1 に答える 1

0

排他ロックは CREATE ... SELECT クエリからではなく、同じトランザクション内にある必要があるその前のクエリからのものであることがわかりました。

重要な詳細を省略しました: CREATE ... SELECT クエリは、 の AFTER DELETE トリガーclients_permission_assignmentsです。問題は、DELETE クエリがいくつかのclients_permission_assignmentsレコードに排他ロックを保持していることであり、各削除の後、CREATE ... SELECT クエリは、DELETE クエリからの排他ロックを既に持っているレコードに共有ロックを取得しようとすることがわかりました。CREATE ... SELECT クエリは、すべての行が削除され、排他ロックが解放されるまで待機する必要があります。ただし、このプロセスが行われている間、ユーザーは待機を楽しんでいなかったため、DELETE クエリを再度開始したため、デッドロックが発生しました。

ありがとうございました。

于 2011-05-12T15:57:16.877 に答える