в my.cnf ничего не трогать если есть сомнения. Если на сервере уже есть какие-то данные и он медленно работает, то разбираться что работает медленно и под это дело менять конфиги

что такое route не ясно, наверное это зависит от используемого языка программирования и библиотек ORM

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

Можешь

Но не простым селектом :)

Быстрый ответ. Если стоит transaction_isolation = REPEATABLE-READ то нет.
Если стоит READ-COMMITED, то да.

а каким?)

Длинный ответ начинается с вопроса - "а зачем Вам это нужно?"

асинхронная модель, на проекте так исторически сложилось, приходится костылять

Можно и в repeatable read получить

Если блокирующий доступ к строке

это какие то флаги?

ну понял, спасибо, это то, что нужно

Коллеги по несчастью, прошу помощи с направлением в котором нужно копать.
Дано:
MySQL: 5.7.22-22-log Percona Server (GPL), Release 22, Revision f62d93c
pt-online-schema-change version 3.1.0

При запуске pt-osc приложение рапортует: "SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction"

В это время на стороне InnoDB показывается следующая диагностика:

------------------------
LATEST DETECTED DEADLOCK
------------------------
2020-05-14 13:57:29 0x7fb0136f6700
*** (1) TRANSACTION:
TRANSACTION 9067056094, ACTIVE 0 sec setting auto-inc lock
mysql tables in use 2, locked 2
LOCK WAIT 6 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1
...
REPLACE INTO `DB`.`_table_new` ... 
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
TABLE LOCK table `db`.`_table_new` trx id 9067056094 lock mode AUTO-INC waiting
*** (2) TRANSACTION:
TRANSACTION 9067056090, ACTIVE 0 sec inserting
mysql tables in use 2, locked 2
18 lock struct(s), heap size 1136, 456 row lock(s), undo log entries 443
INSERT LOW_PRIORITY IGNORE INTO `db`.`_table_new` ....
*** (2) HOLDS THE LOCK(S):
TABLE LOCK table `db`.`_table_new` trx id 9067056090 lock mode AUTO-INC
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 2901 page no 6596 n bits 584 index k_transaction_id of table `db`.`_table_new` trx id 9067056090 lock_mode X locks gap before rec insert intention waiting
*** WE ROLL BACK TRANSACTION (1)

Конфиг сервера:
innodb_lock_wait_timeout = 50
lock_wait_timeout = 31536000

Как я вижу эту проблему: приложение пишет в основную таблицу, запускается триггер и пытается записать обновление в теневую таблицу. Это обновление конфликтует с записью которую делает сам pt-osc за блокировку автоинкремента.

Что пытался сделать: уменьшил --chunk-size до 500 количество дедлоков упало, но они остались. Вопрос: как заставить падать pt-osc вместо приложения?

Буду рад идеям.

innodb_lock_wait_timeout не имеет отношения к "LATEST DETECTED DEADLOCK". Попробуйте innodb_auto_inc_lock_mode=2

спасибо большое! Минусы у такого подхода есть?

я читал, что возможна потеря данных

binlog_format=ROW автоматически включится при binlog_format=mixed, возможны дырки в значении автоинкремента (1, 2, 3, 5, 10, 11 ...). Но не будет затупов на 8+ запросах делающих инсёрты в одну табличку.\

Тогда иннодб ни разу не acid с 2?)

спасибо!