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

ну, в этом случае for update не нужен

если про это

про это,но автор как я понял хотел что-то вроде системы очередей сделать

чтобы захватить строку и больше ее никто заюзать не смог

чтобы захватить строку и больше ее никто заюзать не смог

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

ну, в этом случае for update не нужен

Т.е. в моём случае использование FOR UPDATE не имеет смысла, т.к. внутренний механизм сам разрулит эту ситуацию ?

насколько понимаю, да (головой сейчас немного в других облаках)

Т.е. в моём случае использование FOR UPDATE не имеет смысла, т.к. внутренний механизм сам разрулит эту ситуацию ?

нужен

иначе блокировка на строку будет в момент обновления

а не в момент старта транзакции

не в момент чтения?

нет, там неблокирующее чтение, строка читается из снепшота

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

правильно я понимаю, что в каждой транзакции нужно взять первого незанятого водителя, пометить его как занятого, а потом дальше с его id что-то сделать?

правильно я понимаю, что в каждой транзакции нужно взять первого незанятого водителя, пометить его как занятого, а потом дальше с его id что-то сделать?

Да. Правильно понимаете.

Так, теперь уже для тупого меня. Там же REPEATABLE READ по умолчанию. Разве он не гарантирует, что между r1 ... w1 не будет другой записи?

в смысле я понял про блокировку, но не понимаю важности этого момента

Да. Правильно понимаете.

Тогда самым правильным решением будет SELECT ... FOR UPDATE SKIP LOCKED. Но это только с 8.0: https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html

там в самом конце страницы есть пример, иллюстрирующий что это такое

если есть возможность использовать 8.0, то лучше её. иначе придётся костыли городить

сомневаюсь что кто-то еще в проде её юзает... но не об этом сейчас

ну, не всё, что разработчики используют, обязательно используется в проде

даже чаще наоборот :)

а не в момент старта транзакции

Хочу подвести небольшой итог: 1. FOR UPDATE использовать! 2. Это в свою очередь гарантирует, что необходимое мне поведение будет достигнуто.

Верно я понял ?

Так, теперь уже для тупого меня. Там же REPEATABLE READ по умолчанию. Разве он не гарантирует, что между r1 ... w1 не будет другой записи?

вот сильное заявление, нужно осмыслить, возможно он и лишний будет

Хочу подвести небольшой итог: 1. FOR UPDATE использовать! 2. Это в свою очередь гарантирует, что необходимое мне поведение будет достигнуто.

не совсем. простой FOR UPDATE заблокирует параллельные транзакции, пока текущая не закончится. это может быть приемлимым, а может и нет — зависит от приложения

Тогда самым правильным решением будет SELECT ... FOR UPDATE SKIP LOCKED. Но это только с 8.0: https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html

Очень интересно. Обязательно посмотрю. Правда боюсь падений в продакшене. Просто на носу опытная эксплуатация.

ну если на носу, тогда да, не надо 8.0

огосподи

что это за дичь

?

уже эмодзи не оттправишь

не совсем. простой FOR UPDATE заблокирует параллельные транзакции, пока текущая не закончится. это может быть приемлимым, а может и нет — зависит от приложения

1. Я так понимаю, решение также затронет производительность в целом? 2. Какие мне еще нужно рассмотреть критерии прежде чем убедиться, что мне необходимо использование FOR UPDATE ?

Затронет производительность

потому что for update это неявный serializable будет, возможна эскалация блокировок и все будет работать медленнее

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

Так, теперь уже для тупого меня. Там же REPEATABLE READ по умолчанию. Разве он не гарантирует, что между r1 ... w1 не будет другой записи?

между r1 и w1 не будет, но благодарая for update r2 из параллельной транзакции не начнется пока не будет коммита

во

если один-два, то вряд ли небеса рухнут

1. Я так понимаю, решение также затронет производительность в целом? 2. Какие мне еще нужно рассмотреть критерии прежде чем убедиться, что мне необходимо использование FOR UPDATE ?

1. Да, все транзакции будут по сути выполнятся одна за другой. Это может и не быть проблемой. Главное следить, чтобы внутри транзакции потом не делалось что-то долгое, типа отправки письма или что-то в этом духе. Сделать минимальную работу, которую нужно сделать на стороне СУБД и закоммитить 2. Да тут выбор небольшой. Можно обойтись без FOR UPDATE, но будет или такая же сериализация, или небезопасно с точки зрения параллельных транзакций

если один-два, то вряд ли небеса рухнут

Ситуация следующая: В одной густонаселенной местности могут одновременно прийти от 10 до сотни запросов, если радиус поиска в 3км. Из этого следует максимум 100 запросов теоритических. Вот если исходить из этих данных, то стоит ли ?

если транзакции быстрые - почему нет?

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

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

Отлично. Благодарю.

1. Да, все транзакции будут по сути выполнятся одна за другой. Это может и не быть проблемой. Главное следить, чтобы внутри транзакции потом не делалось что-то долгое, типа отправки письма или что-то в этом духе. Сделать минимальную работу, которую нужно сделать на стороне СУБД и закоммитить 2. Да тут выбор небольшой. Можно обойтись без FOR UPDATE, но будет или такая же сериализация, или небезопасно с точки зрения параллельных транзакций

В целом понял. Благодарю.

если 100 транзакций в секунду в пике, но каждая транзакция занимает не более 1/100 секунды, то нет никаких проблем, даже если они сериализуются. Ваш К.О. :)

если 100 транзакций в секунду в пике, но каждая транзакция занимает не более 1/100 секунды, то нет никаких проблем, даже если они сериализуются. Ваш К.О. :)

удваиваю этого господина

Всем спасибо за развернутые ответы и за дельные советы!

Ситуация следующая: В одной густонаселенной местности могут одновременно прийти от 10 до сотни запросов, если радиус поиска в 3км. Из этого следует максимум 100 запросов теоритических. Вот если исходить из этих данных, то стоит ли ?

Сто запросов - это пик, или постоянная нагрузка?

Если пик, то я бы не стал сильно волноваться

Сто запросов - это пик, или постоянная нагрузка?

Да, 100 запросов это теоритический пик в ЧНН, с одной области радиусом в 3км.

Если пик, то я бы не стал сильно волноваться

Отлично.

Ребят можете плиз накидать пару книжек, чтобы детальнее разобраться в тонкостях, относительно блокировок в mysql (mariadb) и так далее. (Язык не имеет значения, но если есть актуальное издание на русском, то было бы супер.)

Документация

Подробнее чем там вряд ли где будет

Подробнее чем там вряд ли где будет

Вот это печально. Потому что я с него начал разбираться. Там с примерами туговато, как мне показалось.

https://www.microsoft.com/en-us/research/publication/a-critique-of-ansi-sql-isolation-levels/ вот в этой бумаге хорошо расписано, какие уровни изоляции с какими феноменами борются

(целиком я ее так и не прочитал)

https://habrahabr.ru/post/238513/

https://www.youtube.com/watch?v=mSQrRvo6l9I

это вот прям из первых уст

если нужен прямо совсем хардкор, то могу вот это рекомендовать: https://www.slideshare.net/valeriikravchuk1/understanding-innodb-locks-and-deadlocks

Во, спасибо за материалы. Почитаю/Посмотрю.

но в High Performance MySQL наверняка это всё в более удобнов виде описано

в книжке орейли с вороной?)

про блокировки там почти нет ничего, в основном упор на query performance

я уже не помню, щас проверю

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

там есть еще одна, тоже с птичкой, тоже про мускуль, тоже полезная)

Талманн автор

Привет всим

11 июля состоится встреча московской группы пользователей MySQL http://www.opennet.ru/opennews/art.shtml?num=46788 11 июля в 18:00 в офисе компании Mail.Ru состоится очередная встреча московской группы пользователей MySQL (Moscow MySQL User Group). Специальный гость встречи - Пётр Зайцев (CEO, Percona). Пётр сделает два доклада и ответит на вопросы участников встречи. Вход свободный. #opennet

Всем привет. Ребят у меня тут вопрос есть. Чтобы запрос r2 и w2 блокировались пока не исполнится r1 и w2 нужно обязательно делать запрос вида SELECT ...FOR UPDATE и оборачивать в транзакцию ? ИЛи нужно уровни изоляции трогать ещё ?

Всем привет. Ребят у меня тут вопрос есть. Чтобы запрос r2 и w2 блокировались пока не исполнится r1 и w2 нужно обязательно делать запрос вида SELECT ...FOR UPDATE и оборачивать в транзакцию ? ИЛи нужно уровни изоляции трогать ещё ?

Просто у меня как бы всё ещё возникают ситуации, когда один и тот же водитель с флагом "ЗАНЯТ" может прийти на запросы вида SELECT .. FOR UPDATE завернутые в транзакции.

Просто у меня как бы всё ещё возникают ситуации, когда один и тот же водитель с флагом "ЗАНЯТ" может прийти на запросы вида SELECT .. FOR UPDATE завернутые в транзакции.

а как выглядят запросы?

почему вот это плохо:

mysqldump -uroot -p database > utf8.dump

а вот это хорошо:

mysqldump -uroot -p database -r utf8.dump

а кто сказал, что (а) - это а плохо, а (б) - хорошо, и что при этом было сказано дополнительно?

могу лишь предположить, что автор думал, что при использовании редиректа файл сначала будет создан целиком в оперативке - конечно, это не так

но что на самом деле думал автор, конечно, не знаю

всем привет! )

ребят, подскажите пожалуйста что делать: имеется большая БД (80 гигов), её нужно перенести на другой сервак

весь день убил - ума не приложу как

делать mysqldump - это смертоубийство, до нового года дампить буду, а потом еще столько же разворачивать на новом серве :(

пробовал файлами копировать - получается быстро (~2 часа), но БД после этого не работает (хотя делал по доке)