Почему InnoDB CREATE ... SELECT использует эксклюзивную блокировку? - PullRequest
Новая
       45

Почему InnoDB CREATE ... SELECT использует эксклюзивную блокировку?

0 голосов
/ 12 мая 2011

Я пытаюсь обернуть голову вокруг тупика 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) блокировка, я могу попытаться обойти эту тупиковую ситуацию.Или, может быть, я мог бы получить дополнительную помощь с тупиком.

Спасибо.

1 Ответ

0 голосов
/ 12 мая 2011

Я обнаружил, что эксклюзивная блокировка была не из запроса CREATE ... SELECT, а из запроса перед ним, который должен быть в той же транзакции.

Я пропустил важную деталь: запрос CREATE ... SELECT является триггером AFTER DELETE на clients_permission_assignments. Я обнаружил, что проблема заключалась в том, что запрос DELETE удерживает монопольные блокировки некоторых записей clients_permission_assignments, и после каждого удаления запрос CREATE ... SELECT пытается получить общую блокировку для записи, которая уже имеет монопольную блокировку от DELETE. запрос. Запрос CREATE ... SELECT должен ожидать удаления всех строк и снятия исключительных блокировок. Однако, пока этот процесс происходил, пользователь не наслаждался ожиданием, поэтому он снова начал запрос DELETE, что привело к тупику.

Спасибо.

...