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

уровни изоляции трогать не надо, в транзакцию оборачивать надо

а как на это смотрите http://skeletor.org.ua/?p=3401 ?

innodb не поддерживает копирование файлами, это только с myisam канает

не жизнеспособно?

80Gb в транзакциях - это до седовласой старости переносить

есть же percona xtrabackup, зачем велосипеды придумывать

а он может сделать бэкап сразу на другой сервер?

а то основная проблема собсн вот в чем: /dev/xvdb1 99G 84G 11G 90% /var/lib/mysql

раздел 99G, из него занято 84G

т.е. "положить" бэкап на этот же сервак - не получится (

а он может сделать бэкап сразу на другой сервер?

может. называется streaming backup

вот тут примеры: https://www.percona.com/doc/percona-xtrabackup/LATEST/howtos/recipes_ibkx_stream.html

спасибо огромное!!!!

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

Внутри транзакции делаю выборку 1 водителя, достаю его id и тут же делаю UPDATE строки по id. где ставлю in_search = 1

уровни изоляции трогать не надо, в транзакцию оборачивать надо

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

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

странно, да. а водители в таблице точно все уникальные?

Внутри транзакции делаю выборку 1 водителя, достаю его id и тут же делаю UPDATE строки по id. где ставлю in_search = 1

а в select у тебя in_search = 0 учитывается?

а в select у тебя in_search = 0 учитывается?

Да.

Можно сюда скинуть запрос ?

да

лучше даже транзакцию целиком

START TRANSACTION; SELECT id, is_busy, first_name, last_name, role, msisdn, thumbnail, lat, lon, car, device_id, drivers.serial_number, ( :radiusOfEarth * acos ( cos ( radians(:lat) ) * cos( radians( lat ) ) * cos( radians( lon ) - radians(:lon) ) + sin ( radians(:lat) ) * sin( radians( lat ) ) ) ) AS distance FROM ( SELECT u.id, is_busy, first_name, last_name, role,msisdn, thumbnail, lat, lon, CONCAT(c.color,' ',c.brand,' ',c.model) as car, c.serial_number, dev.device_id FROM users u JOIN car_info c ON u.car_id=c.id JOIN devices as dev ON dev.user_id = u.id WHERE is_busy = 1 AND status = 1 AND role = 'passanger_car' AND u.car_id IS NOT NULL AND is_offline = 1 AND u.id NOT IN (23) AND u.in_search_flag = 0 ) as drivers HAVING distance < :distance ORDER BY distance LIMIT 0 , :num FOR UPDATE; UPDATE users u SET in_search_flag = 1 WHERE id = 24; COMMIT;

лучше даже транзакцию целиком

Да это вся транзакция, больше ничего нет.

Правильно ли я ожидаю, что такая же параллельная транзакция по идее, должна ждать предыдущую ?

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

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

да, перенеси for update в подзапрос

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

Блин, я даже не предполагал о таком.

да, перенеси for update в подзапрос

Сейчас попробую. Спасибо.

Не знаю как for update внутри работает, скорее всего блокировка будет на результат подзапроса, а этот результат - временная табличка, поэтому хоть заблокируйтесь - вне запроса она и так никому не доступна, а раз только на результат, то таблицы самого подзапроса свободны, поэтому второй запрос спокойно будет работать сам по себе. Только интересно: а со вьюхами так же будет? Вроде ни чем не отличается от примера, но с другой стороны - два запроса будут с одной и той же вьюхой работать. Или вьюхе нельзя for update ставить?

Да, на результат подзапроса, только что проверил

А с вьюхами как?

во вьюхе не т смысла делать такое

Я для общего развития. For update как и вьюхи не пользую )

Да, на результат подзапроса, только что проверил

Да, тоже проверил.Работает как нужно. Спасибо большое. Весь день потратил на это.

Всем спасибо.

во вьюхах сам по себе функционал ограничен

да и это попахивает выстрелом в колено

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

А она есть)

во первых там два вида алгоритмов создания вьюх

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

а во втором случае эта вьха будет как обычный запрос

с вьюхами будет работать только в случае если ты будешь делать select * from view for update и работать это будет только в случае, если вьюха обновляемая, что накладывает еще ряд ограничений на код внутри вьюхи

короче это жопа

START TRANSACTION; SELECT id, is_busy, first_name, last_name, role, msisdn, thumbnail, lat, lon, car, device_id, drivers.serial_number, ( :radiusOfEarth * acos ( cos ( radians(:lat) ) * cos( radians( lat ) ) * cos( radians( lon ) - radians(:lon) ) + sin ( radians(:lat) ) * sin( radians( lat ) ) ) ) AS distance FROM ( SELECT u.id, is_busy, first_name, last_name, role,msisdn, thumbnail, lat, lon, CONCAT(c.color,' ',c.brand,' ',c.model) as car, c.serial_number, dev.device_id FROM users u JOIN car_info c ON u.car_id=c.id JOIN devices as dev ON dev.user_id = u.id WHERE is_busy = 1 AND status = 1 AND role = 'passanger_car' AND u.car_id IS NOT NULL AND is_offline = 1 AND u.id NOT IN (23) AND u.in_search_flag = 0 ) as drivers HAVING distance < :distance ORDER BY distance LIMIT 0 , :num FOR UPDATE; UPDATE users u SET in_search_flag = 1 WHERE id = 24; COMMIT;

Скорее всего, подзапрос выполняется через временную таблицу (легко проверить с помощью EXPLAIN) и тогда FOR UPDATE действительно пойдёт на временную таблицу, а не на базовую. Но зачем там вообще подзапрос?

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

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

А как тогда быть в ситуация когда подзапрос всё-таки нужен ?

А как тогда быть в ситуация когда подзапрос всё-таки нужен ?

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

здесь-то подзапрос не нужен совсем вроде?

а кстати какая версия mysql?

а кстати какая версия mysql?

5.6.28

здесь-то подзапрос не нужен совсем вроде?

Здесь не нужен. Но есть же другие запросы. Как быть если у меня есть запрос такой. Почему блокировка не распространяется на весь запрос ?

А да, я этот запрос много раз переписывал поэтому там раньше ещё была логика. Я её выкинул.

подзапросы вида SELECT ... FROM (SELECT ...) называются derived tables

у оптимизатора есть две стратегии выполнения таких запросов: 1. объединить подзапрос во внешний запрос и 2. материализовать подзапрос во временную таблицу, а внешний запрос выполнять по ней

видимо, оптимизатор из каких-то своих соображений решил использовать вариант 2. я не помню, есть ли в 5.6 вариант 1, в 5.7 уже точно есть

а раз внешний запрос выполняется по временной таблице, то и for update работает на ней

EXPLAIN конечно покажет, какая стратегия используется. но FOR UPDATE + подзапросы это в любом случае плохая идея, потому что зависит от выбора оптимизатора

EXPLAIN конечно покажет, какая стратегия используется. но FOR UPDATE + подзапросы это в любом случае плохая идея, потому что зависит от выбора оптимизатора

Теперь понятно. Спасибо за разъяснения. Буд знать теперь.

но интересный случай. я бы написал запрос на bugs.mysql.com, чтобы это внесли в документацию

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

Тоже работает как надо. Одно из решений данной проблемы. Это я про простой запрос который идёт следом после основной выборки.

хотя тут скорее даже теоретический вопрос. каково правильное поведение SELECT ... FROM (SELECT ...) FOR UPDATE с точки зрения SQL стандарта, например?

ведь в подзапросе может вообще не быть базовой таблицы. например SELECT * FROM (SELECT 1) FOR UPDATE, на какие строчки тут ставить блокировки?

собственно, просто select 1 for update mysql отрабатывает молча, хотя в этой команде нет никакого смысла

кстати, постгрес точно так же себя ведёт. select 1 for update отрабатывается тоже молча

ребят, подскажите пожалуйста, а innobackupex умеет не через mysql.sock подключаться?

а по хосту

блин :(

Failed to connect to MySQL server: Plugin 'auth_socket' is not loaded.

и всё тут :(

ребят, подскажите пожалуйста, а innobackupex умеет не через mysql.sock подключаться?

есть опции --host и --port

собственно, просто select 1 for update mysql отрабатывает молча, хотя в этой команде нет никакого смысла

Да интересно. Мне кажется ,это сделано для случаев, если в выборке участвуют вычисляемые данные помимо реальных. ЧТобы ошибок не возникало.

В 5.6 нет derived merge

видимо, оптимизатор из каких-то своих соображений решил использовать вариант 2. я не помню, есть ли в 5.6 вариант 1, в 5.7 уже точно есть

И фича так себе я вам скажу

хотя тут скорее даже теоретический вопрос. каково правильное поведение SELECT ... FROM (SELECT ...) FOR UPDATE с точки зрения SQL стандарта, например?

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

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

я-то знаю. вопрос о том, как правильно субд должна реагировать на запрос select 1 for update. вот mysql и postgresql молча возвращают 1

Это же не строка

Это константа)

Данные он же не из стораджа берет

да, и хорошо бы ругнуться, что выражение for update не имеет смысла. а все молча выполняют

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

Мускуль это не про "ругаться" )

и постгрес тоже получается

я поэтому задался вопросом, что sql стандарт говорит. но пока нет времени выяснять

Оно того не стоит, я думаю

ну вот сегодня убедительный был пример, что стоит

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

ну вот сегодня убедительный был пример, что стоит

Я не знаю как работают внутри другие СУБД, но имею некоторое представление о том как работает MySQL, поэтому, увидев запрос, сразу предположил то поведение, которое и наблюдалось. Поэтому "стоит" знать инструмент, а не стандарты ) по стандартам HTML все круто должно быть, но в браузерах все совсем не так )))

Я не знаю как работают внутри другие СУБД, но имею некоторое представление о том как работает MySQL, поэтому, увидев запрос, сразу предположил то поведение, которое и наблюдалось. Поэтому "стоит" знать инструмент, а не стандарты ) по стандартам HTML все круто должно быть, но в браузерах все совсем не так )))

я не о том. проблема есть, вопрос в том, как правильнее было бы её исправить. и тут нужно посмотреть на другие СУБД (в постгресе судя по всему всё так же плохо) или на стандарт

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

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

"как обойти" и "как исправить" — разные вещи. ответ на первый вопрос мне был понятен с самого начала, меня больше второй интересовал

че-то я не догоняю, пойду сдохну )

Привет. Ребята. Как парсить xml файл размером 20 гиг и больше средствами php?

Такое возможно?

Возможно, но долго будет

И памяти нужно много

Может разбивать файл?