Процедура взаимоблокировки MySQL: анализ странной проблемы взаимоблокировки пакетной вставки

Недавно появились онлайн-партииinsertТупик, я не могу думать об этом, сестра. Записи взаимоблокировки следующие

2018-10-26T11:04:41.759589Z 8530809 [Note] InnoDB: 
*** (1) TRANSACTION:

TRANSACTION 1202026765, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 8532863, OS thread handle 139858337453824, query id 16231472122 10.111.10.143 seewo update
INSERT IGNORE INTO xx_performance_type_label_relation(label_id, performance_type_id, type, create_time)
    VALUES
      
      ('bb0394e670644168a998a93a3ed521bc', '06b96ee0bab84d71bb17bf9645d3aa54', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '27d82e2331b241e1a9c9c0a74ec21099', -1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '3100b5978fb24f56b327d25732a7d7a7', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '435a1e19ce6e4e5bbb84240b3b34cf03', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '447fe27199ca40e289ef2834469d9a78', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '87a52c4d00844b5bb9eb75e8fe34202a', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', 'c6a0e26983bd4fae837d5ee2f4efeef8', 1, now())
2018-10-26T11:04:41.759635Z 8530809 [Note] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 505 page no 9912 n bits 288 index uk_performance_type_id_label_id of table `masaike`.`xx_performance_type_label_relation` trx id 1202026765 lock_mode X locks gap before rec insert intention waiting
2018-10-26T11:04:41.759674Z 8530809 [Note] InnoDB: *** (2) TRANSACTION:

TRANSACTION 1202026764, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
MySQL thread id 8530809, OS thread handle 139858469242624, query id 16231472119 10.111.10.153 seewo update
INSERT IGNORE INTO xx_performance_type_label_relation(label_id, performance_type_id, type, create_time)
    VALUES
      
      ('bb0394e670644168a998a93a3ed521bc', '06b96ee0bab84d71bb17bf9645d3aa54', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '27d82e2331b241e1a9c9c0a74ec21099', -1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '3100b5978fb24f56b327d25732a7d7a7', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '435a1e19ce6e4e5bbb84240b3b34cf03', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '447fe27199ca40e289ef2834469d9a78', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', '87a52c4d00844b5bb9eb75e8fe34202a', 1, now())
     , 
      ('bb0394e670644168a998a93a3ed521bc', 'c6a0e26983bd4fae837d5ee2f4efeef8', 1, now())
2018-10-26T11:04:41.759713Z 8530809 [Note] InnoDB: *** (2) HOLDS THE LOCK(S):

RECORD LOCKS space id 505 page no 9912 n bits 288 index uk_performance_type_id_label_id of table `masaike`.`xx_performance_type_label_relation` trx id 1202026764 lock mode S
2018-10-26T11:04:41.759753Z 8530809 [Note] InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED:

RECORD LOCKS space id 505 page no 9912 n bits 288 index uk_performance_type_id_label_id of table `masaike`.`xx_performance_type_label_relation` trx id 1202026764 lock_mode X locks gap before rec insert intention waiting
2018-10-26T11:04:41.759784Z 8530809 [Note] InnoDB: *** WE ROLL BACK TRANSACTION (2)

Первой реакцией является вставка партиями, а тупиковая ситуация возникает из-за разного порядка вставок. Но это не здесь. Есть две причины

Последовательность пакетной вставки SQL, о которой идет речь, точно такая же. В случае той же последовательности будет выполняться только ожидание вставки (от неявной блокировки до явной блокировки X). Ниже приведены эксперименты.
Если это связано с журналом взаимоблокировок, вызванным несогласованным порядком вставки пакетов, напечатанный результат не является ожиданием намерения вставки (ожидание намерения вставки), ниже приведены эксперименты.

Теперь возьмите упрощенную таблицу и проведите эксперимент

CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` varchar(5)  NOT NULL DEFAULT '',
  `b` varchar(5)  NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_name` (`a`,`b`)
) ENGINE=InnoDB;

Эксперимент 01

В случае, если запись не существует, одновременно выполняются две пакетные вставки в одном порядке, а второй будет находиться в состоянии ожидания блокировки

во-первыхtruncate t1;

t1	t2
begin;	begin;
insert ignore into t1(a, b)values("1", "1");		успех
	insert ignore into t1(a, b)values("1", "1");	состояние ожидания блокировки

Вы можете увидеть текущий статус блокировки

mysql> select * from information_schema.innodb_locks;
+-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+
| lock_id     | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
+-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+
| 31AE:54:4:2 | 31AE        | S         | RECORD    | `d1`.`t1`  | `uk_name`  |         54 |         4 |        2 | '1', '1'  |
| 31AD:54:4:2 | 31AD        | X         | RECORD    | `d1`.`t1`  | `uk_name`  |         54 |         4 |        2 | '1', '1'  |
+-------------+-------------+-----------+-----------+------------+------------+------------+-----------+----------+-----------+

пока мы занимаемся бизнесомt1При вставке не появляется в точке останова какой-либо блокировки, что связано с принципом вставки MySQL

insert 加的是隐式锁。什么是隐式锁？隐式锁的意思就是没有锁

Когда запись вставляется в момент t1, она разблокируется. В это время, когда транзакция t1 не была зафиксирована, когда транзакция t2 пытается вставить, она обнаруживает, что эта запись существует, и t2 пытается получить блокировку S, и она определяет, активен ли идентификатор транзакции в записи. Помогите t1 преобразовать его неявную блокировку в явную блокировку (блокировку X)

Исходный код выглядит следующим образом

т2 получитьSРезультат блокировки:DB_LOCK_WAIT

Эксперимент 02

Журнал взаимоблокировок, вызванный несогласованным порядком пакетной вставки, не ожидает блокировки намерения вставки.

t1	t2
begin
insert into t1(a, b)values("1", "1");		успех
	insert into t1(a, b)values("2", "2");	успех
insert into t1(a, b)values("2", "2");		t1 пытается получить блокировку S, переводит неявную блокировку t2 в явную блокировку X и входит в состояние DB_LOCK_WAIT.
	insert into t1(a, b)values("1", "1");	t2 пытается получить блокировку S и обновляет неявную блокировку t1 до явной блокировки X, что приводит к тупиковой ситуации.

------------------------
LATEST DETECTED DEADLOCK
------------------------
181101  9:48:36
*** (1) TRANSACTION:
TRANSACTION 3309, ACTIVE 215 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 2
MySQL thread id 2, OS thread handle 0x70000a845000, query id 58 localhost root update
insert into t1(a, b)values("2", "2")
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 3309 lock mode S waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 1; hex 32; asc 2;;
 1: len 1; hex 32; asc 2;;
 2: len 4; hex 80000002; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 330A, ACTIVE 163 sec inserting
mysql tables in use 1, locked 1
3 lock struct(s), heap size 376, 2 row lock(s), undo log entries 2
MySQL thread id 3, OS thread handle 0x70000a888000, query id 59 localhost root update
insert into t1(a, b)values("1", "1")
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 330A lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 1; hex 32; asc 2;;
 1: len 1; hex 32; asc 2;;
 2: len 4; hex 80000002; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 4 n bits 72 index `uk_name` of table `d1`.`t1` trx id 330A lock mode S waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 1; hex 31; asc 1;;
 1: len 1; hex 31; asc 1;;
 2: len 4; hex 80000001; asc     ;;

*** WE ROLL BACK TRANSACTION (2)

До сих пор был тупик, и нет абсолютно никакого способа воспроизвести тупиковую ситуацию. Прочитав код, я обнаружил, что есть удаление перед вставкой, но удаление и вставка не находятся в одной транзакции, то есть после отправки удаления выполняется пакетная вставка.Настоящая проблема именно в пакетной вставке. С самого начала исключено влияние удаления на бэк.Это не транзакция, она тоже повлияет?

Я написал код для имитации, есть большая вероятность, что он воспроизведется

fun test() {
    dao.delete() // 对应delete from
    // sleep for 10ms
    dao.insert() // 对应insert ignore
}

Соответствующий SQL выглядит следующим образом, обратите внимание, что есть две транзакции

begin;
delete from t1 where a = '25'
commit;

begin;
INSERT ignore INTO `t1` (`a`, `b`) VALUES('25','1')
commit;

Когда этот код вызывается двумя потоками одновременно, очень легко зайти в тупик.

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

Если он помечен как удаленный, значит, транзакция была зафиксирована и времени на очистку нет, то последующая транзакция добавляетSожидание блокировки;

Распечатайте несколько журналов в исходном коде. 1. Вstorage/innobase/row/row0ins.cизrow_ins_set_shared_rec_lockУвеличьте журнал, вы можете увидеть, что уникальный индекс увеличиваетсяSпроцесс блокировки

if (dict_index_is_clust(index)) {
    err = lock_clust_rec_read_check_and_lock(
        0, block, rec, index, offsets, LOCK_S, type, thr);
} else {
    err = lock_sec_rec_read_check_and_lock(
        0, block, rec, index, offsets, LOCK_S, type, thr);
    // 增加如下日志
    fprintf(stderr, "row_ins_set_shared_rec_lock %s %lu %d\n" , index->name, type, err);
}

2. Вlock_rec_enqueue_waitingУвеличьте журнал, вы можете увидеть ситуацию ожидания блокировки

static
enum db_err
lock_rec_enqueue_waiting(
{
	fprintf(stderr, "lock_rec_enqueue_waiting::::: %s %lu\n" , index->name, type_mode);
}

Лог примерно такой

row_ins_set_shared_rec_lock uk_name 0 9 (t1获取S锁成功）
row_ins_set_shared_rec_lock uk_name 0 9 (t2获取S锁成功）

lock_rec_enqueue_waiting::::: uk_name 2563（t1 X锁进如锁等待）
lock_rec_enqueue_waiting::::: uk_name 2563（t2 X锁进如锁等待）

Где 2563=2048+512+3=LOCK_INSERT_INTENTION+LOCK_GAP+LOCK_X

Этот процесс имеет точно такой же принцип, как очень классическая вставка трех транзакций в одно и то же время, одна откатывается, одна завершается успешно и одна блокируется для оставшихся двух транзакций.

Эксперимент 03

Три игнорирования вставки, одна взаимоблокировка, вызванная откатом

операторы вставкиinsert ignore into t1(a, b)values("1", "1");Опущено ниже

t1	t2	t3	Примечание
begin	begin	begin
insert			успех
	insert		Повысьте неявную блокировку t1 до блокировки X, t2 входит в блокировку S и ожидает
		insert	t3 входит в ожидание блокировки S
rollback;			После отката t1 блокировка X снимается, а t2 и t3 одновременно получают блокировку S.
	ok	deadlock	И t2, и t3 хотят получить блокировку X блокировки намерения вставки, что приводит к тупиковой ситуации.

Журнал взаимоблокировок, точно так же, как и в нашем случае

------------------------
LATEST DETECTED DEADLOCK
------------------------
181101 23:22:59
*** (1) TRANSACTION:
TRANSACTION 5032, ACTIVE 11 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1248, 2 row lock(s), undo log entries 1
MySQL thread id 5, OS thread handle 0x70000d736000, query id 125 localhost root update
insert ignore into t1(a, b)values("1", "1")
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 56 page no 4 n bits 584 index `uk_name` of table `d1`.`t1` trx id 5032 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 139 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 3; hex 313031; asc 101;;
 1: len 3; hex 313031; asc 101;;
 2: len 4; hex 800007b1; asc     ;;

*** (2) TRANSACTION:
TRANSACTION 5033, ACTIVE 6 sec inserting
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1248, 2 row lock(s), undo log entries 1
MySQL thread id 6, OS thread handle 0x70000d779000, query id 126 localhost root update
insert ignore into t1(a, b)values("1", "1")
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 56 page no 4 n bits 584 index `uk_name` of table `d1`.`t1` trx id 5033 lock mode S locks gap before rec
Record lock, heap no 139 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 3; hex 313031; asc 101;;
 1: len 3; hex 313031; asc 101;;
 2: len 4; hex 800007b1; asc     ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 56 page no 4 n bits 584 index `uk_name` of table `d1`.`t1` trx id 5033 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 139 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 3; hex 313031; asc 101;;
 1: len 3; hex 313031; asc 101;;
 2: len 4; hex 800007b1; asc     ;;

*** WE ROLL BACK TRANSACTION (2)

Пока выводы такие:

Запись, которая была зафиксирована, но не очищена, приведет к тому, что последующая вставка получит общую блокировку S. Две транзакции одновременно получают блокировку S, а затем пытаются получить блокировку намерения вставки, что приводит к взаимоблокировке.

Процесс вставки онлайн-богов

Сначала добавьте замки Insert Intension Locks к вставленному промежутку.
- Если разрыв был добавлен с блокировкой GAP или блокировкой Next-Key, блокировка не выполняется и начинается ожидание;
- Если нет, блокировка выполнена успешно, что означает, что ее можно вставить;
Затем оцените, имеет ли вставленная запись уникальный ключ, и если да, выполните проверку ограничения уникальности.
- Если такое же значение ключа не существует, завершите вставку
- Если такое же значение ключа существует, определите, заблокировано ли значение ключа.
  - Если блокировки нет, определить, помечена ли запись на удаление
  - Если он помечен как удаленный, значит, транзакция была зафиксирована и времени на очистку нет, тогда добавляем S-блокировку для ожидания;
  - Если нет помеченного удаления, будет сообщено об ошибке дублирования ключа 1062;
- Если есть блокировка, значит запись находится в обработке (добавление, удаление или обновление), а транзакция не была зафиксирована, добавляем S блокировку и ждем;
Вставьте запись и добавьте блокировку записи X к записи;

Выше приведены некоторые выводы, которые я сделал из исходного кода отладки. Если я ошибаюсь, оставьте сообщение и дайте мне знать.

Ниже приведены справочные документы

Woohoo. Нажмите easy stone.com/archives/20…
Woohoo. Нажмите easy stone.com/archives/20…
Он Dengcheng.com/?Afraid=844#_TOC…