powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Deadlock на insret нескольких строк из-за autoincrement
36 сообщений из 36, показаны все 2 страниц
Deadlock на insret нескольких строк из-за autoincrement
    #39809308
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
что то я после оракла слегка в ступоре: innodb табличка с одним autoincrement pk полем, параллельные тразакции инсертят в нее в стиле insert into ... select несколько строк. pk поле не упоминаю, оно типа заполняется само.
и тут я получаю дедлок, как я понимаю одна из вариаций вот этого: https://dba.stackexchange.com/questions/28058/how-to-analyse-innodb-status-on-deadlock-in-insert-query/28289#28289

а как с этим жить? мне как бы и нечего сортировать, pk назначает мне autoincement
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39810192
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
запрос?
граф дедлока?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39810955
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowзапрос?
граф дедлока?

я удалил пока пк и проблема спустилась чуть ниже по транзакции. и она продолжает ставить меня в тупик:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-05-07 19:35:30 7f4a5748a700
*** (1) TRANSACTION:
TRANSACTION 12291417, ACTIVE 0 sec starting index read
mysql tables in use 2, locked 2
LOCK WAIT 406 lock struct(s), heap size 46632, 54095 row lock(s), undo log entries 4
MySQL thread id 1648312, OS thread handle 0x7f4a570ec700, query id 21648823 xx.xx.xx.xx oc5z Sending data
UPDATE deal_product_rows p SET status= 'D', deletetion_date = now() WHERE deal_id = 9612 and status<>'D'  AND NOT EXISTS (SELECT 1 FROM deal_product_rows_tmp t                     WHERE t.deal_id = p.deal_id                       and t.batch_no=5354                      and p.product_id = t.product_id)
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 206 page no 3 n bits 184 index `GEN_CLUST_INDEX` of table `db1`.`deal_product_rows_tmp` trx id 12291417 lock mode S waiting
Record lock, heap no 6 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
 0: len 6; hex 0000001031f6; asc     1 ;;
 1: len 6; hex 000000bb8d52; asc      R;;
 2: len 7; hex ab0000016e0110; asc     n  ;;
 3: len 4; hex 800014e9; asc     ;;
 4: len 4; hex 800fca6a; asc    j;;
 5: len 4; hex 8000251a; asc   % ;;
 6: len 4; hex 8000968a; asc     ;;
 7: len 4; hex 80000001; asc     ;;
 8: len 30; hex 4152544558206172747967656c2030303120d0bad180d0b0d181d0bdd18b; asc product 001             ; (total 41 bytes);
 9: len 8; hex 0000000000507040; asc      Pp@;;
 10: len 1; hex 4d; asc M;;

*** (2) TRANSACTION:
TRANSACTION 12291410, ACTIVE 1 sec starting index read
mysql tables in use 2, locked 2
6 lock struct(s), heap size 1184, 3 row lock(s), undo log entries 119
MySQL thread id 1648305, OS thread handle 0x7f4a5748a700, query id 21648929 xx.xx.xx.xx oc5z updating
UPDATE deal_product_rows p SET status= 'D', deletetion_date = now() WHERE deal_id = 9498 and status<>'D'  AND NOT EXISTS (SELECT 1 FROM deal_product_rows_tmp t                     WHERE t.deal_id = p.deal_id                       and t.batch_no=5353                      and p.product_id = t.product_id)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 206 page no 3 n bits 152 index `GEN_CLUST_INDEX` of table `db1`.`deal_product_rows_tmp` trx id 12291410 lock_mode X locks rec but not gap
Record lock, heap no 6 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
 0: len 6; hex 0000001031f6; asc     1 ;;
 1: len 6; hex 000000bb8d52; asc      R;;
 2: len 7; hex ab0000016e0110; asc     n  ;;
 3: len 4; hex 800014e9; asc     ;;
 4: len 4; hex 800fca6a; asc    j;;
 5: len 4; hex 8000251a; asc   % ;;
 6: len 4; hex 8000968a; asc     ;;
 7: len 4; hex 80000001; asc     ;;
 8: len 30; hex 4152544558206172747967656c2030303120d0bad180d0b0d181d0bdd18b; asc product 001             ; (total 41 bytes);
 9: len 8; hex 0000000000507040; asc      Pp@;;
 10: len 1; hex 4d; asc M;;

как я понимаю столкнулись два UPDATE на таблицу deal_product_rows. но не поделил они чтение из deal_product_rows_tmp ? innodb же вроде версионник, откуда в таких запросах могут взяться блокировки на deal_product_rows_tmp ?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811042
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
deal_product_rows_tmp тоже innodb?

ps
подробностей уже не помню, но сталкивался с тем, что подзапросы вида where exists/not exists (select ) блокировали таблицу, указанную в подзапросе
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811099
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дегтярев Евгенийdeal_product_rows_tmp тоже innodb?

ps
подробностей уже не помню, но сталкивался с тем, что подзапросы вида where exists/not exists (select ) блокировали таблицу, указанную в подзапросе

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-05-08 06:16:23 7f4a5769a700
*** (1) TRANSACTION:
TRANSACTION 12314813, ACTIVE 1 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 13 lock struct(s), heap size 2936, 355 row lock(s), undo log entries 110
MySQL thread id 1654182, OS thread handle 0x7f4a57658700, query id 21892885 xx.xx.xx.xx oc5z updating
DELETE FROM deal_product_rows_tmp WHERE batch_no=5754
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 219 page no 3 n bits 168 index `PRIMARY` of table `db1`.`deal_product_rows_tmp` trx id 12314813 lock_mode X waiting
Record lock, heap no 88 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
 0: len 4; hex 80001bb9; asc     ;;
 1: len 6; hex 000000bbe8c0; asc       ;;
 2: len 7; hex be000001b50110; asc        ;;
 3: len 4; hex 8000167b; asc    {;;
 4: len 4; hex 800fe7c4; asc     ;;
 5: len 4; hex 80002516; asc   % ;;
 6: len 4; hex 8000986e; asc    n;;
 7: len 4; hex 80000003; asc     ;;
 8: len 30; hex 415254455820d184d0bed180d0bcd18b20d0bfd180d18fd0bcd0bed183d0; asc PROD                        ; (total 81 bytes);
 9: len 8; hex 0000000000208c40; asc        @;;
 10: len 1; hex 4d; asc M;;

*** (2) TRANSACTION:
TRANSACTION 12314816, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
14 lock struct(s), heap size 2936, 95 row lock(s), undo log entries 14
MySQL thread id 1654175, OS thread handle 0x7f4a5769a700, query id 21892888 xx.xx.xx.xx oc5z updating
DELETE FROM deal_product_rows_tmp WHERE batch_no=5755
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 219 page no 3 n bits 168 index `PRIMARY` of table `db1`.`deal_product_rows_tmp` trx id 12314816 lock_mode X locks rec but not gap
Record lock, heap no 25 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
как у него RECORD LOCK на разные строки столкнулись друг с другом ? даже если он пытается одну и ту же страницу индекса залочить, как может это вызвать дедлок !? зачем тут устраивать дедлок, какие проблемы подождать пока одна транзакция отпустит эту страницу ?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811110
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
start transaction isolation level read committed
update ....
commit
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811113
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вторая транзакция "lock_mode X locks rec but not gap".

авторHere's what's happening:

Transaction 2 gets a lock for the (index) record but not the gap before the record ('rec but not gap'), i.e. it has a record lock only.
Transaction 1 tries to get a lock on the record and the gap before (i.e. a next-key lock), but can't because transaction 2 has a record lock (and so transaction 1 waits).
Transaction 2 tries to get a lock on the record and the gap before (i.e. a next-key lock) and can't because Transaction 1 is already waiting for the same lock and is ahead of it in the queue.
Deadlock.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811114
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowstart transaction isolation level read committed
update ....
commit
сначала бы хотелось понять суть проблемы. так как глючат совершенно разные запросы. от инсертов до апдейтов с exists. откуда может быть дедлок при row level locking ? откуда может быть дедлок если им нужна одна и та же страница индекса ? один ставит лок, второй ждет, где дедлок ?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811115
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторкак у него RECORD LOCK на разные строки столкнулись друг с другом

по умолчанию уровень изоляции repeatable read - а он требует еще и локов на диапазоны, а не только на саму запись.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811119
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторHere's what's happening:

Transaction 2 gets a lock for the (index) record but not the gap before the record ('rec but not gap'), i.e. it has a record lock only.
Transaction 1 tries to get a lock on the record and the gap before (i.e. a next-key lock), but can't because transaction 2 has a record lock (and so transaction 1 waits).
Transaction 2 tries to get a lock on the record and the gap before (i.e. a next-key lock) and can't because Transaction 1 is already waiting for the same lock and is ahead of it in the queue.
Deadlock.


если тут lock on the record имеется ввиду лок на конкретную строку то тут описывается примитивный дедлок, где транзакции дерутся за одну и ту же строку. у меня транзакции вообще не пересекаются никак. у меня каждая транзакция удаляет свой набор строк
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811124
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторtries to get a lock on the record a nd the gap before (i.e. a next-key lock)

https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html#innodb-next-key-locks
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811126
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторкак у него RECORD LOCK на разные строки столкнулись друг с другом

по умолчанию уровень изоляции repeatable read - а он требует еще и локов на диапазоны, а не только на саму запись.
допустим. а откуда тогда дедлок ? одна транзакция ставит, другая ждет. в чем сложности? может он ставит лок по одной записи на кусок диапазона ? почему в сообщении RECORD LOCK ?
RECORD LOCKS space id 219 page no 3 n bits 168 index `PRIMARY`

выглядит что транзакция 1 ставит на все строки страницы индекса RECORD LOCK в одном направлении, а транзакция 2 ставит на каждую в другом направлении. какой-то абсурд.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811130
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторкакой-то абсурд.

авторпо умолчанию уровень изоляции repeatable read - а он требует еще и локов на диапазоны
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811136
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторвычитал что при отсутствии pk innodb начинает свои GEN_CLUST_INDEX индексы строить
при отсутствии первичного innodb сам создает его, он всегда кластерный

зы
давай уже версию сервера, DLL таблиц, autocommit или явное управление транзакциями, уровень изоляции таблиц
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811150
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторкакой-то абсурд.

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

Дегтярев Евгенийпри отсутствии первичного innodb сам создает его, он всегда кластерный

зы
давай уже версию сервера, DLL таблиц, autocommit или явное управление транзакциями, уровень изоляции таблиц

транзакция из java/spring, дефолтная, repeatable read, метод помечен @Transactional анатацией. сервер google cloud mysql gen 1

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
 SHOW VARIABLES LIKE "%version%";
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_version          | 5.6.39     |
| protocol_version        | 10         |
| slave_type_conversions  |            |
| version                 | 5.6.39-log |
| version_comment         | (Google)   |
| version_compile_machine | x86_64     |
| version_compile_os      | Linux      |
+-------------------------+------------+
7 rows in set (0.01 sec)
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39811616
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hck1,

на read committed та же ботва, два делита и точно такой-же дедлок:

Код: plaintext
1.
RECORD LOCKS space id 219 page no 3 n bits 112 index `PRIMARY` of table `db1`.`deal_product_rows_tmp` trx id 12336911 lock_mode X locks rec but not gap waiting
RECORD LOCKS space id 219 page no 3 n bits 112 index `PRIMARY` of table `db1`.`deal_product_rows_tmp` trx id 12336913 lock_mode X locks rec but not gap
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812119
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
запросы покажи?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812352
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowзапросы покажи?

выше показывал и запросы и дедлок . все то же самое на IL read committed

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-05-08 23:35:28 7f4a572fc700
*** (1) TRANSACTION:
TRANSACTION 12336911, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 8 lock struct(s), heap size 1184, 37 row lock(s), undo log entries 73
MySQL thread id 1668546, OS thread handle 0x7f4a5733e700, query id 22337604 xx.xx.xx.xx oc5z updating
DELETE FROM deal_product_rows_tmp WHERE batch_no=5845
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 219 page no 3 n bits 112 index `PRIMARY` of table `db1`.`deal_product_rows_tmp` trx id 12336911 lock_mode X locks rec but not gap waiting
Record lock, heap no 37 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
 0: len 4; hex 80002638; asc   &8;;
 1: len 6; hex 000000bc3f11; asc     ? ;;
 2: len 7; hex e0000001c00110; asc        ;;
 3: len 4; hex 800016d6; asc     ;;
 4: len 4; hex 800ff03a; asc    :;;
 5: len 4; hex 8000246a; asc   $j;;
 6: len 4; hex 800095b0; asc     ;;
 7: len 4; hex 80000001; asc     ;;
 8: len 29; hex d094d0bed181d182d0b0d0b2d0bad0b020d0b7d0b0d0bad0b0d0b7d0b0; asc                              ;;
 9: len 8; hex 3333333333bb7240; asc 33333 r@;;
 10: len 1; hex 4d; asc M;;

*** (2) TRANSACTION:
TRANSACTION 12336913, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
8 lock struct(s), heap size 1184, 3 row lock(s), undo log entries 8
MySQL thread id 1668549, OS thread handle 0x7f4a572fc700, query id 22337609 xx.xx.xx.xx oc5z updating
DELETE FROM deal_product_rows_tmp WHERE batch_no=5846
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 219 page no 3 n bits 112 index `PRIMARY` of table `db1`.`deal_product_rows_tmp` trx id 12336913 lock_mode X locks rec but not gap
Record lock, heap no 37 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
 0: len 4; hex 80002638; asc   &8;;
 1: len 6; hex 000000bc3f11; asc     ? ;;
 2: len 7; hex e0000001c00110; asc        ;;
 3: len 4; hex 800016d6; asc     ;;
 4: len 4; hex 800ff03a; asc    :;;
 5: len 4; hex 8000246a; asc   $j;;
 6: len 4; hex 800095b0; asc     ;;
 7: len 4; hex 80000001; asc     ;;
 8: len 29; hex d094d0bed181d182d0b0d0b2d0bad0b020d0b7d0b0d0bad0b0d0b7d0b0; asc                              ;;
 9: len 8; hex 3333333333bb7240; asc 33333 r@;;
 10: len 1; hex 4d; asc M;;
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812370
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ddl таблиц покажи.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812385
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowddl таблиц покажи.

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
     CREATE TABLE `deal_product_rows_tmp` (
      `batch_no` int(11) NOT NULL,
      `bitrix_id` int(11) NOT NULL,
      `deal_id` int(11) NOT NULL,
      `product_id` int(11) NOT NULL,
      `quantity` int(11) NOT NULL,
      `product_name` varchar(1000) NOT NULL,
      `price` double DEFAULT NULL,
      `status` varchar(50) NOT NULL,
      `tmp_id` int(11) NOT NULL AUTO_INCREMENT,
      PRIMARY KEY (`tmp_id`),
      KEY `idx_deal_row_tmp_deal` (`deal_id`),
      KEY `idx_deal_row_tmp_batchno` (`batch_no`)
    ) ENGINE=InnoDB AUTO_INCREMENT=7500 DEFAULT CHARSET=utf8 
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812421
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
explain DELETE FROM deal_product_rows_tmp WHERE batch_no=5846



?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812432
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrow,
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
 explain DELETE FROM deal_product_rows_tmp WHERE batch_no=5846 ;
+----+-------------+-----------------------+-------+--------------------------+--------------------------+---------+-------+------+-------------+
| id | select_type | table                 | type  | possible_keys            | key                      | key_len | ref   | rows | Extra       |
+----+-------------+-----------------------+-------+--------------------------+--------------------------+---------+-------+------+-------------+
|  1 | SIMPLE      | deal_product_rows_tmp | range | idx_deal_row_tmp_batchno | idx_deal_row_tmp_batchno | 4       | const |    1 | Using where |
+----+-------------+-----------------------+-------+--------------------------+--------------------------+---------+-------+------+-------------+
1 row in set (0.01 sec)

не знаю на сколько это имеет значение для предполагаемого плана, но сейчас в табличке то пусто. то что было наинсерчено батчем 5846 убрал роллбэк убитой дедлоком транзакции.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812434
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
так у тя дедлок не на двух делетах?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812437
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowтак у тя дедлок не на двух делетах?
вопрос не понял, но вот в этом логе фигурирует два DELETE
https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1312130&msg=21883030

DELETE FROM deal_product_rows_tmp WHERE batch_no=5845
DELETE FROM deal_product_rows_tmp WHERE batch_no=5846
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812438
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторто что было наинсерчено батчем 5846 убрал роллбэк убитой дедлоком транзакции.
а что это значит?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39812448
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторто что было наинсерчено батчем 5846 убрал роллбэк убитой дедлоком транзакции.
а что это значит?
забей. меня интересуют пояснения от того кто в курсе что такое дедлок и что он делает с транзакциями.

2All
вопрос все тот же, с чего вдруг 2 делита на разные наборы строк решили поставить record lock на одну и ту же запись ? почему это провоцирует дедлок, а не обычное ожидание ?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816049
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
поставил mysql локально 5.6.39, не работают даже совсем примитивные транзакции.
таблица
Код: sql
1.
2.
3.
4.
5.
CREATE TABLE test1 (
  id int(11) NOT NULL AUTO_INCREMENT,
  name varchar(100),
  PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ;



транзакция 1
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
mysql> SET autocommit = 0;
Query OK, 0 rows affected (0.00 sec)

mysql> 
mysql> SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test1(name) values ('shit1') ;
Query OK, 1 row affected (0.00 sec)



транзакция 2
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
mysql> SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
Query OK, 0 rows affected (0.00 sec)

mysql> SET autocommit = 0;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test1(name) values ('shit2') ;
Query OK, 1 row affected (0.00 sec)



теперь в транзакции 1 удаляем ту самую строку какую вставила эта транзакция
Код: sql
1.
mysql> delete from test1 where name = 'shit1' ;


транзакция 1 уже повисает на блокировке
теперь в транзакции 2 удаляем ее строку

Код: sql
1.
2.
mysql> delete from test1 where name='shit2' ;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction



Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
------------------------
LATEST DETECTED DEADLOCK
------------------------
2019-05-21 19:00:51 7f61fce4a700
*** (1) TRANSACTION:
TRANSACTION 2010, ACTIVE 76 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 360, 2 row lock(s), undo log entries 2
MySQL thread id 14, OS thread handle 0x7f61fce8c700, query id 305 localhost root updating
delete from test1 where name = 'shit1'
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 19 page no 3 n bits 72 index `PRIMARY` of table `db1`.`test1` trx id 2010 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000002; asc     ;;
 1: len 6; hex 0000000007db; asc       ;;
 2: len 7; hex af000001ce0110; asc        ;;
 3: len 5; hex 7368697432; asc shit2;;

*** (2) TRANSACTION:
TRANSACTION 2011, ACTIVE 41 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 360, 2 row lock(s), undo log entries 1
MySQL thread id 13, OS thread handle 0x7f61fce4a700, query id 306 localhost root updating
delete from test1 where name='shit2'
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 19 page no 3 n bits 72 index `PRIMARY` of table `db1`.`test1` trx id 2011 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 4; hex 80000002; asc     ;;
 1: len 6; hex 0000000007db; asc       ;;
 2: len 7; hex af000001ce0110; asc        ;;
 3: len 5; hex 7368697432; asc shit2;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 19 page no 3 n bits 72 index `PRIMARY` of table `db1`.`test1` trx id 2011 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 32
 0: len 4; hex 80000001; asc     ;;
 1: len 6; hex 0000000007da; asc       ;;
 2: len 7; hex 2e000001d10110; asc .      ;;
 3: len 5; hex 7368697431; asc shit1;;

*** WE ROLL BACK TRANSACTION (2)

в mysql 8 чуток реже, но в принципе примерно ту же хрень получаю. как же так !?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816327
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторкак же так
тут как раз всё просто. без уникального индекса по полю во where надо просмотреть всю таблицу. транзакция 1 уже держит лок на shit1, транзакция 2 на shit2 и они пытаются получить лок друг на друга.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816347
H5N1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторкак же так
тут как раз всё просто. без уникального индекса по полю во where надо просмотреть всю таблицу. транзакция 1 уже держит лок на shit1, транзакция 2 на shit2 и они пытаются получить лок друг на друга.
не понимаю.
во первых откуда транзакция1 знает о shit2 строке? транзакция2 не закомиченна, выходит что транзакция1 читает грязные данные.
во вторых зачем ставить локи на не входящие в предикат строки ? у транзакции1 предикат name='shit1', даже если она фулсканит таблицу, зачем ставить лок на все подрят ?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816403
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторо первых откуда транзакция1 знает о shit2 строке? транзакция2 не закомиченна, выходит что транзакция1 читает грязные данные.

чтобы понять что строка не видна текущей транзакции, логично, что надо её прочитать.

автордаже если она фулсканит таблицу, зачем ставить лок на все подрят ?

у нас же row locking, да.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816481
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторо первых откуда транзакция1 знает о shit2 строке? транзакция2 не закомиченна, выходит что транзакция1 читает грязные данные.

чтобы понять что строка не видна текущей транзакции, логично, что надо её прочитать.

и это объявляется транзакцией? ну да, на одной странице данных есть строки которые транзакция "видит", есть которые не видит. mysql обязан игнорить незакомиченные данные иначе это уже не транзакция. иначе это откровенное нарушение изоляции транзакций.

ScareCrowавтордаже если она фулсканит таблицу, зачем ставить лок на все подрят ?

у нас же row locking, да.
row locking это когда субд блокирует ровно те записи, что необходимо. тут же mysql вместо конкретных записей пытается заблокировать целиком всю таблицу. это уже противоположность row level locks и называется lock escalation.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816489
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторmysql обязан игнорить незакомиченные данные

как он поймет что это незакоммиченные до того как их прочитает?

автортут же mysql вместо конкретных записей пытается заблокировать целиком всю таблицу

это не так от слова совсем.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816501
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторmysql обязан игнорить незакомиченные данные

как он поймет что это незакоммиченные до того как их прочитает?

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

ScareCrowавтортут же mysql вместо конкретных записей пытается заблокировать целиком всю таблицу

это не так от слова совсем.
это так. не стоит спорить. если блокируется больше, чем необходимо это не row level locking.
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816516
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторна страницу данных ставится латч
а если там УЖЕ латч?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816517
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор вот тогда в таблицу блокировок ставиться лок

а если нет таблицы блокировок?
...
Рейтинг: 0 / 0
Deadlock на insret нескольких строк из-за autoincrement
    #39816563
hck1
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторна страницу данных ставится латч
а если там УЖЕ латч?
значит читать страницу не безопасно и нужно ждать когда конкурирующий процесс, например записи страницы на диск, отпустит страницу.

ScareCrowавтор вот тогда в таблицу блокировок ставиться лок

а если нет таблицы блокировок?
тогда это оракл, который хранит блокировки на странице данных и "версионность" накладывает не на отдельные строки, а целиком страницу. но это на сколько я знаю не про innodb. innodb хранит в памяти список (таблицу) блокировок.
...
Рейтинг: 0 / 0
36 сообщений из 36, показаны все 2 страниц
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Deadlock на insret нескольких строк из-за autoincrement
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]