Назад | Перейти на главную страницу

нужна помощь в понимании тупика

У меня тупик ниже при беге insert into заявления. Какова возможная причина этого и как вы предлагаете ее решить?

LATEST DETECTED DEADLOCK
------------------------
2020-01-01 06:56:20 0x7fbfa9c4f700
*** (1) TRANSACTION:
TRANSACTION 3770369752, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 3
MySQL thread id 583875, OS thread handle 140464586606336, query id 1343761255 172.16.0.73 be update
INSERT INTO hourly_creative_stats (date_hour, account_id, campaign_id, creative_id,placement_id, bid) VALUES (date_format(utc_timestamp(),'%Y-%m-%d %H'),3,164807,123318,42667,1) ON DUPLICATE KEY UPDATE bid=bid+values(bid)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1558 page no 909823 n bits 120 index PRIMARY of table `ubimo`.`hourly_creative_stats` trx id 3770369752 lock_mode X locks rec but not gap waiting
Record lock, heap no 12 PHYSICAL RECORD: n_fields 22; compact format; info bits 0
 0: len 5; hex 99a5426000; asc   B` ;;
 1: len 4; hex 8000a6ab; asc     ;;
 2: len 4; hex 000283c7; asc     ;;
 3: len 4; hex 0001e1bb; asc     ;;
 .....    

*** (2) TRANSACTION:
TRANSACTION 3770369751, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
5 lock struct(s), heap size 1136, 7 row lock(s), undo log entries 6
MySQL thread id 594879, OS thread handle 140461163738880, query id 1343761256 172.16.11.48 fe update
INSERT INTO hourly_creative_stats (date_hour,creative_id,campaign_id,placement_id,account_id,won) values (date_format('2020-01-01 06:56:20.0','%Y-%m-%d %H'),123319,164807,42667,3,1) ON DUPLICATE KEY UPDATE won=won+values(won)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 1558 page no 909823 n bits 120 index PRIMARY of table `ubimo`.`hourly_creative_stats` trx id 3770369751 lock_mode X locks rec but not gap
Record lock, heap no 12 PHYSICAL RECORD: n_fields 22; compact format; info bits 0
 0: len 5; hex 99a5426000; asc   B` ;;
 1: len 4; hex 8000a6ab; asc     ;;
 2: len 4; hex 000283c7; asc     ;;
 3: len 4; hex 0001e1bb; asc     ;;
 4: len 6; hex 0000e0bb46d7; asc     F ;;
 5: len 7; hex 0700003b670507; asc    ;g  ;;
 6: len 4; hex 00000024; asc    $;;
 ....

*** WE ROLL BACK TRANSACTION (1)

Схема таблицы:

CREATE TABLE `hourly_creative_stats` (
  `date_hour` datetime NOT NULL,
  `account_id` int(10) NOT NULL,
  `placement_id` int(10) NOT NULL,
  `campaign_id` int(10) unsigned NOT NULL,
  `creative_id` int(10) unsigned NOT NULL,
  `bid` int(10) unsigned NOT NULL DEFAULT '0',
  `won` int(10) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY `date_hour`,`placement_id`,`campaign_id`,`creative_id`),
  INDEX (`campaign_id`),
  INDEX (`account_id`, `date_hour`)
);

Пожалуйста, покажите использование всего SQL между BEGIN и COMMIT.

Возможное решение: ускорить выполнение всей транзакции (с помощью кажущейся несвязанной оптимизации)

Резервный вариант: будьте готовы поймать тупик и воспроизвести всю транзакцию. Это должно быть реализовано в любом случае. Даже если вы избавитесь от одного тупика, другой может выскочить.

Дополнительное обсуждение сводных таблиц. Ваш подход IODKU разумен, однако в моем документе представлены другие способы. Они могут быть интересны.

Возможные причины:

1) Конфликт распределения автоматического увеличения. Посмотрите на режимы блокировки автоматического увеличения.

2) Вы запускаете это на виртуальной машине или в AWS RDS? Виртуализация на хосте, который переполнен или имеет шумных соседей, может вызвать странное дрожание часов, которое может существенно нарушить синхронизацию параллельных операций, чтобы вызвать ложные взаимоблокировки, даже если теоретически нет возможности для возникновения взаимоблокировки. Я видел это в RDS много раз, особенно на экземплярах меньшего размера и t-класса.