mysql держит и ждет такой же блокировки

0

Я работаю над mysql5.6.34 с innoDB. Произошел тупик, и я получаю show engine innodb status. Я не знаю, как произошел тупик, и почему TRANSACTION-2 держится и ждет того же Х-замка, а затем ROLLBACK?
журналы:

------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-08-15 05:58:56 7fdff5872700
*** (1) TRANSACTION:
TRANSACTION 81567872, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 2
MySQL thread id 455326, OS thread handle 0x7fdff9083700, query id 255309181 10.8.201.34 slnbdata update
INSERT INTO XXX

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 8065 page no 11084 n bits 192 index 'PRIMARY' of table 'XXX' trx id 81567872 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) TRANSACTION:
TRANSACTION 81567879, ACTIVE 0 sec inserting
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1184, 2 row lock(s), undo log entries 2
MySQL thread id 455338, OS thread handle 0x7fdff5872700, query id 255309187 10.8.201.34 slnbdata update
INSERT INTO XXX

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 8065 page no 11084 n bits 192 index 'PRIMARY' of table 'XXX' trx id 81567879 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 8065 page no 11084 n bits 192 index 'PRIMARY' of table 'XXX' trx id 81567879 lock_mode X insert intention waiting
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

*** WE ROLL BACK TRANSACTION (2)
------------
TRANSACTIONS
------------
There do have a query before the insert:
SELECT
    pk_1,
    max(pk_2)
FROM
    table
WHERE
    pk_1 IN (...)
GROUP BY
    pk_1
but no queries between each insert.
And let me correct my reply above, the insert statement is:
insert into table_name(pk_1,pk_2 ...) values (1,1_1 ...) and insert into table_name(pk_1,pk_2 ...) values (2,2_1 ...)
We use foreach of mybatis like this:
   <insert id="save">
        <foreach collection="list" item="item" separator=";">
            INSERT INTO ...
CREATE TABLE 'customer_address_info' (
  'customer_no' char(10) NOT NULL,
  'addr_index' int(1) unsigned NOT NULL,
  'addr_type' tinyint(1) NOT NULL,
  'province_code' char(6) DEFAULT NULL,
  'province_name' varchar(20) DEFAULT NULL,
  'city_code' char(6) DEFAULT NULL,
  'city_name' varchar(50) DEFAULT NULL,
  'county_code' char(6) DEFAULT NULL,
  'county_name' varchar(100) DEFAULT NULL,
  'zip_code' char(6) DEFAULT NULL,
  'detail' varchar(100) NOT NULL,
  'status' tinyint(4) unsigned NOT NULL,
  'create_date' datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  'create_user' varchar(30) NOT NULL,
  'modify_date' datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
  'modify_user' varchar(30) DEFAULT NULL,
  PRIMARY KEY ('customer_no','addr_index')
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  • 0
    каково ваше заявление вставки?
  • 0
    вставить в table_name (pk, ...) значения (1, ...) и вставить в table_name (pk, ...) значения (2, ...)
Показать ещё 16 комментариев
Теги:
transactions
deadlock
innodb

1 ответ

0

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

Показатель Show ENGINE INNODB STATUS указывает, что каждая транзакция заблокировала две строки и имеет два ожидающих совершенных изменения (блокировка 2 строки, записи журнала отмены 2), поэтому в одной транзакции должны быть другие операторы, которые не отображаются.

Транзакция 1 ожидает блокировки IX, которая предотвращает блокировку X транзакцией 2; Транзакция 2 ждет блокировки IX, которая выполняется транзакцией 1.

IX можно было бы получить путем выбора * из таблицы для обновления. Оператор select, добавленный OP, является простым выбором и не требует блокировки.

Поскольку ваш уровень изоляции - REPEATABLE_READ, который по умолчанию используется в MySQL, каждый замок, полученный во время транзакции, удерживается на протяжении всей транзакции, поэтому вам необходимо проанализировать запросы с начала транзакции до тех пор, пока оператор insert не увидит возможные блокировки, приобретенные,

Ещё вопросы

Сообщество Overcoder
Наверх
Меню