|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
что то я после оракла слегка в ступоре: 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 ... |
|||
:
Нравится:
Не нравится:
|
|||
02.05.2019, 17:10 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
запрос? граф дедлока? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 13:53 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
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.
как я понимаю столкнулись два UPDATE на таблицу deal_product_rows. но не поделил они чтение из deal_product_rows_tmp ? innodb же вроде версионник, откуда в таких запросах могут взяться блокировки на deal_product_rows_tmp ? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2019, 22:47 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
deal_product_rows_tmp тоже innodb? ps подробностей уже не помню, но сталкивался с тем, что подзапросы вида where exists/not exists (select ) блокировали таблицу, указанную в подзапросе ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 05:29 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
Дегтярев Евгений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.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 09:38 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
start transaction isolation level read committed update .... commit ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 09:50 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
вторая транзакция "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. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 09:56 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ScareCrowstart transaction isolation level read committed update .... commit сначала бы хотелось понять суть проблемы. так как глючат совершенно разные запросы. от инсертов до апдейтов с exists. откуда может быть дедлок при row level locking ? откуда может быть дедлок если им нужна одна и та же страница индекса ? один ставит лок, второй ждет, где дедлок ? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 09:59 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
авторкак у него RECORD LOCK на разные строки столкнулись друг с другом по умолчанию уровень изоляции repeatable read - а он требует еще и локов на диапазоны, а не только на саму запись. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 09:59 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
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 имеется ввиду лок на конкретную строку то тут описывается примитивный дедлок, где транзакции дерутся за одну и ту же строку. у меня транзакции вообще не пересекаются никак. у меня каждая транзакция удаляет свой набор строк ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 10:04 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
автор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 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 10:06 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ScareCrowавторкак у него RECORD LOCK на разные строки столкнулись друг с другом по умолчанию уровень изоляции repeatable read - а он требует еще и локов на диапазоны, а не только на саму запись. допустим. а откуда тогда дедлок ? одна транзакция ставит, другая ждет. в чем сложности? может он ставит лок по одной записи на кусок диапазона ? почему в сообщении RECORD LOCK ? RECORD LOCKS space id 219 page no 3 n bits 168 index `PRIMARY` выглядит что транзакция 1 ставит на все строки страницы индекса RECORD LOCK в одном направлении, а транзакция 2 ставит на каждую в другом направлении. какой-то абсурд. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 10:10 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
авторкакой-то абсурд. авторпо умолчанию уровень изоляции repeatable read - а он требует еще и локов на диапазоны ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 10:16 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
авторвычитал что при отсутствии pk innodb начинает свои GEN_CLUST_INDEX индексы строить при отсутствии первичного innodb сам создает его, он всегда кластерный зы давай уже версию сервера, DLL таблиц, autocommit или явное управление транзакциями, уровень изоляции таблиц ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 10:22 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 10:36 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
hck1, на read committed та же ботва, два делита и точно такой-же дедлок: Код: plaintext 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.05.2019, 08:33 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
запросы покажи? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.05.2019, 22:34 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
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.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2019, 09:20 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ddl таблиц покажи. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2019, 10:00 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ScareCrowddl таблиц покажи. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2019, 10:54 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
Код: sql 1.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2019, 11:36 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ScareCrow, Код: plaintext 1. 2. 3. 4. 5. 6. 7.
не знаю на сколько это имеет значение для предполагаемого плана, но сейчас в табличке то пусто. то что было наинсерчено батчем 5846 убрал роллбэк убитой дедлоком транзакции. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2019, 11:50 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
так у тя дедлок не на двух делетах? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2019, 11:53 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
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 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2019, 11:57 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
авторто что было наинсерчено батчем 5846 убрал роллбэк убитой дедлоком транзакции. а что это значит? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2019, 11:59 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ScareCrowавторто что было наинсерчено батчем 5846 убрал роллбэк убитой дедлоком транзакции. а что это значит? забей. меня интересуют пояснения от того кто в курсе что такое дедлок и что он делает с транзакциями. 2All вопрос все тот же, с чего вдруг 2 делита на разные наборы строк решили поставить record lock на одну и ту же запись ? почему это провоцирует дедлок, а не обычное ожидание ? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2019, 12:07 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
поставил mysql локально 5.6.39, не работают даже совсем примитивные транзакции. таблица Код: sql 1. 2. 3. 4. 5.
транзакция 1 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
транзакция 2 Код: sql 1. 2. 3. 4. 5. 6. 7. 8.
теперь в транзакции 1 удаляем ту самую строку какую вставила эта транзакция Код: sql 1.
транзакция 1 уже повисает на блокировке теперь в транзакции 2 удаляем ее строку Код: sql 1. 2.
Код: 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.
в mysql 8 чуток реже, но в принципе примерно ту же хрень получаю. как же так !? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2019, 22:17 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
авторкак же так тут как раз всё просто. без уникального индекса по полю во where надо просмотреть всю таблицу. транзакция 1 уже держит лок на shit1, транзакция 2 на shit2 и они пытаются получить лок друг на друга. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 12:12 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ScareCrowавторкак же так тут как раз всё просто. без уникального индекса по полю во where надо просмотреть всю таблицу. транзакция 1 уже держит лок на shit1, транзакция 2 на shit2 и они пытаются получить лок друг на друга. не понимаю. во первых откуда транзакция1 знает о shit2 строке? транзакция2 не закомиченна, выходит что транзакция1 читает грязные данные. во вторых зачем ставить локи на не входящие в предикат строки ? у транзакции1 предикат name='shit1', даже если она фулсканит таблицу, зачем ставить лок на все подрят ? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 12:32 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
авторо первых откуда транзакция1 знает о shit2 строке? транзакция2 не закомиченна, выходит что транзакция1 читает грязные данные. чтобы понять что строка не видна текущей транзакции, логично, что надо её прочитать. автордаже если она фулсканит таблицу, зачем ставить лок на все подрят ? у нас же row locking, да. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 13:07 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ScareCrowавторо первых откуда транзакция1 знает о shit2 строке? транзакция2 не закомиченна, выходит что транзакция1 читает грязные данные. чтобы понять что строка не видна текущей транзакции, логично, что надо её прочитать. и это объявляется транзакцией? ну да, на одной странице данных есть строки которые транзакция "видит", есть которые не видит. mysql обязан игнорить незакомиченные данные иначе это уже не транзакция. иначе это откровенное нарушение изоляции транзакций. ScareCrowавтордаже если она фулсканит таблицу, зачем ставить лок на все подрят ? у нас же row locking, да. row locking это когда субд блокирует ровно те записи, что необходимо. тут же mysql вместо конкретных записей пытается заблокировать целиком всю таблицу. это уже противоположность row level locks и называется lock escalation. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 14:02 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
авторmysql обязан игнорить незакомиченные данные как он поймет что это незакоммиченные до того как их прочитает? автортут же mysql вместо конкретных записей пытается заблокировать целиком всю таблицу это не так от слова совсем. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 14:07 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ScareCrowавторmysql обязан игнорить незакомиченные данные как он поймет что это незакоммиченные до того как их прочитает? так как делают взрослые субд. на страницу данных ставится латч, страница считывается, если таймстемп записи выше чем таймстемп транзакции то запись для этой тразакции "невидима". локи ставить на такую запись табу. если запись "видима", вот тогда в таблицу блокировок ставиться лок. тут важно что сначала читается страница, потом уже лок выставляется. и не на все подряд, а только на то что реально нужно залочить. ScareCrowавтортут же mysql вместо конкретных записей пытается заблокировать целиком всю таблицу это не так от слова совсем. это так. не стоит спорить. если блокируется больше, чем необходимо это не row level locking. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 14:22 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
авторна страницу данных ставится латч а если там УЖЕ латч? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 14:34 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
автор вот тогда в таблицу блокировок ставиться лок а если нет таблицы блокировок? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 14:35 |
|
Deadlock на insret нескольких строк из-за autoincrement
|
|||
---|---|---|---|
#18+
ScareCrowавторна страницу данных ставится латч а если там УЖЕ латч? значит читать страницу не безопасно и нужно ждать когда конкурирующий процесс, например записи страницы на диск, отпустит страницу. ScareCrowавтор вот тогда в таблицу блокировок ставиться лок а если нет таблицы блокировок? тогда это оракл, который хранит блокировки на странице данных и "версионность" накладывает не на отдельные строки, а целиком страницу. но это на сколько я знаю не про innodb. innodb хранит в памяти список (таблицу) блокировок. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 15:02 |
|
|
start [/forum/topic.php?all=1&fid=47&tid=1829138]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
55ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
others: | 343ms |
total: | 499ms |
0 / 0 |