Приветствую, уважаемые разработчики!
Спасибо за ваше внимание к моему вопросу!

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

TABLE "users_activity" (MyISAM)
"id" (INT 11) PRIMARY KEY,
"action" (VARCHAR 50),
"flag" (INT 1) INDEX

Здесь "action" - это просто название обработчика (функции), который нужно произвести (обрезка загруженного видео, оптимизация фотографии и т.п.)

А "flag" может быть 0 - задание в очереди, 1 - обрабатывается в данный момент, 2 - готово.

Эта таблица обрабатывается по расписанию несколькими скриптами (параллельно с нескольких серверов), где каждый скрипт берет запись и выполняет ее.

1. Выбирает запись и ставит флаг "в обработке" (чтобы предотвратить параллельное выполнение задачи, которое уже в очереди).



2. Обрабатывает

3. И обновляет флаг, что задача завершена.


Проблема в том, что 1 запрос на выборку уникальной очередной записи часто подвисает на 5-7 секунд.


id>=298122 - для ускорения запроса сохраняю каждый последний успешный id и добавляю его в подзапрос SELECT.

Кроме того, в самой таблице ранее выполненные (flag=1) задания регулярно удаляются, т.е. количество строк в таблице не является безграничным, поддерживается в диапазоне 0-3000 строк одновременно.

Но увы...



Ищу любые идеи оптимизации...

ScareCrow,
"id" (INT 11) PRIMARY KEY,
"flag" (INT 1) INDEX

Akina,

Спасибо за подробный ответ!

Честно говоря, я был уверен что делаю то же самое, только обернуто в один запрос. Выбираю запись и запоминаю ее id, дальше обновляю флаг по этому id. Т.к. MyISAM не поддерживает транзакции, то это единственный выход, который я нашел.

Но Ваша идея интересная, в случае с InnoDB я еще могу использовать транзакцию, в которой будут и SELECT и UPDATE, как Вы предлагаете. Возможно, это решит проблему конкурентных запросов.

Но по поводу InnoDB... У меня сейчас есть другая сторона медали - это еще INSERT-ы в эту таблицу. В MyISAM есть возможность INSERT DELAYED IGNORE, но в InnoDB, похоже, этого нет. Обычный INSERT в случае InnoDB не будет тормозить?

Да, еще добавил составной индекс:


Но разницы не заметно:(

Спасибо всем за помощь.
Финальный SQL:


Explain показывает Range.
В общем, убрав только ORDER BY удалось добиться хорошего результата и скорости. В принципе, в моем случае очередность не столь критична и этим удалось пренебречь.


Как ни странно, но вариант с MIN(id) оказался хуже, Explain показывает All. Но для теста я его оставил и он вызывается 1 на 100 интераций где-то, попробую его тоже поотслеживать на деле и сравню, когда будут данные.