Как правильно работать с большими таблицами?

Question

[leetnigga]

Есть таблица, в которой на данный момент 30 тысяч записей (планируется +/- 100 тыс).

Раз в сутки по крону вызывается скрипт, который проходит по каждой записи в таблице (SELECT * FROM ...), читает из каждой строки пару столбцов (while( $row = mysql_fetch_assoc ) {...}), что-то с ними делает ($foo += $row['foo']).

Вопрос: Правильно ли забирать эти 30 тыс. записей одним большим селектом, или лучше разбить (limit/offset) по тысяче (или по другому количеству)? Или это вообще всё не так делается?

Answer 1

[kifirch]

Лучше выбирать по 1000/5000 записей получать максимальное значение id (PK) и идти дальше, смещаясь по primary key. where id > ? limit 1000 order by id asc
Limit/offset не гуд на больших объемах - так как, к примеру, offset 10000 limit 1000 переберет 10к строчек чтобы отдать 1000

Answer 2

[Melkij]

Как правильно работать с большими таблицами:
положить в таблицу пару лямов записей. Посмотреть на размер этой таблички. Осмыслить, что это какая-то фигня, а не большая таблица. Положить ещё лямов 100.

Вот теперь можно уже разбираться, а нафига вам вообще понадобилось вычитать всю таблицу?
Что-то просуммировать? База это сделает быстрее и лучше и отдаст вам уже готовый аггрегат.
Дёрнуть какие-то внешние вызовы ака очередь? А зачем вам вся таблица? Выбирайте N записей, ещё не обработанных и обрабатывайте их, пока очередной запрос не вернёт 0 записей.
Ещё что-то?
Выгрузить в csv для внешней аналитики? см ответ kifirch

Answer 3

[ThunderCat]

при таких объемах надо смотреть в сторону хранимых процедур. Не дело таскать дохреллион данных между пхп и мускулем, в базу все равно как-то алгоритмично вносятся изменения? Так перенесите логику в бд. Это чисто для бд задача - перелопатить кучу данных из таблицы и внести изменения.