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

[MARDEN]

Если я не ошибаюсь, HANDLER работает только с таблицами MyISAM.

[bvorotnikov]

Как оказалось, нет. По InnoDB прекрасно прошёлся. Хотя в документации сказано только про MyISAM.

[datacompboy]

А просто /tmp/ вынести из tmpfs на жесткий диск, не?
Вместо фиксированной памяти под /tmp/ ограничиться дисковым кешем.

[bvorotnikov]

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

[alex3d]

А почему место в tmpfs кончалось? INSERT FROM SELECT использовали?
Вручную 1 -> SELECT без лимита -> читаем 1000 строк -> INSERT -> 1 не пробовали?
Для INNODB ещё можно было бы в вашем случае заменить OFFSET на id>last_processed_id + ORDER BY id если id-первичный ключ сортировка по которому бесплатна

[bvorotnikov]

INSERT FROM SELECT, конечно, удобная конструкция. Но вопрос не в этом. В данной статье я постарался осветить вопрос последовательного считывания большого количества данных. И основная загвоздка в том, что как бы вы не задавали условие в WHERE, происходит замедление на каждой следующей итерации цикла. Ни id>last_processed_id limit 1000, ни id between last_processed_id and last_processed_id+1000 не дают такую скорость, как HANDLER, потому что HANDLER'у не нужно тратить время на позиционирование указателя на первую запись.

[brammator]

тут можно использовать даже не insert from select, а сразу create from select.