Тонкости работы БД MySQL при одновременной записи и считывании данных из одной таблицы?
Есть таблица в БД MySQL с постоянно обновляемыми и считываемыми данными.
Т.е. один скрипт раз в минуту (по крону) обновляет в ней данные (они получены путем парсинга с API)
Другой скрипт, со стороннего ресурса (не нашего) раз в 15 секунд запрашивает эти данные, путем вызова соответствующего экшена контроллера.
Итак, что происходит, когда они сталкиваются? Т.е. один скрипт пишет в базу, а другой в этот же момент времени считывает из нее. Второй вообще не получит никаких данных или получит только те данные, которые были до обновления первым скриптом?
Недостаточно данных. Разные storage engine будут вести себя разным образом. Для транзакционных storage будут иметь значение уровень изоляции транзакции и собственно как именно реализована транзакционная обработка в обоих приложениях.
innodb, read commited, транзакционная работа писателя: читатель увидит версию данных как будто писатель ничего ещё не делал.
innodb, read commited, нетранзакционная работа писателя/autocommit - читатель увидит какой-то промежуточный результат, что-то обновлено, что-то ещё нет.
myisam - подождёт завершение пишущего запроса (только мешающего запроса! Следующий пишущий запрос постоит подождёт завершение читающего запроса), прочитает текущее состояние
Melkij, у меня писатель работает реально долго, его работу нужно оптимизировать. А читатель обращается реально часто) Поэтому сделал такой логический вывод
у меня писатель работает реально долго, его работу нужно оптимизировать
И это не имеет абсолютно никакого отношения к транзакционной работе.
Если работа с базой из приложения не проектировалась с оглядкой на конкурентный транзакционный доступ - у вас ситуация номер два. Читатель будет получать что-то. Что-то согласованное во времени или какие интересные аномалии - уж как ему повезёт.
sim3x, а что это изменит? Если писатель не учитывает конкурентный доступ - то читатель будет получать аномалии в любой реализации СУБД (и на любом уровне изоляции транзакций). СУБД не будет мешать делать запросы если специально не просить СУБД считать, что вот эта группа запросов должна быть читателям или полностью видна или полностью незаметна.
Егор Казанцев, ACID требует определённое поведение транзакций. Получать интересные аномалии как побочный эффект не учитывающего конкурентный доступ приложения ACID не мешают. Ну а по-умолчанию или нет - утешение слабое и учитывать что речь может быть об этой куче бинарного мусора под видом данных - стоит.
Ошибаетесь.
В СУБД это принято делать по другому. Melkij рядом это хорошо описал.
Там не только очередь, а еще и очень интересная работа с транзакциями и блокировками.
Простой
