Данные за каждый месяц, как лучше реализовать?

Проверил mysqli::query() без MYSQLI_ASYNC на той же таблице, результаты как при использовании PDO: 1 966 866 432

Ааа, понятно. Если RAM на сервере меньше 48Г, то проблема в диске.
Совет один - поможет или RAM до 64Г или SSD.
А 80М строк это немного для чтения - секунд в 30 можно уложится, если без индексов.

При чём тут это? Там (mysqli::query) даже есть пример "/* Если нужно извлечь большой объем данных, используем MYSQLI_USE_RESULT */"

При чём тут это? Там (mysqli::query) даже есть пример "/* Если нужно извлечь большой объем данных, используем MYSQLI_USE_RESULT */"

при том, что я проверяю различные способы и отписываюсь о результатах
сейчас и USE_RESULT проверю

Итак, встречаем победителя - MYSQLI_USE_RESULT - с результатом 524 288 !
Какой-то подозрительный результат на фоне других

Интересное наблюдение - в цикле на первой итерации ставлю var_dump($data); exit;
- результат появляется практически мгновенно и после этого несколько секунд идет работа с хардом.
При других вариантах сначала шуршал хард и только потом появлялся результат. Хотя тут еще буферы могут быть замешаны, перепроверять лень уже.

Так и должно быть, просто данные хранит движок сервера.

Короче я так понял, что с USE_RESULT выборка хранится на стороне сервера и по мере итерации вытягивается инфа оттуда.

PS. опоздал с объяснением

А смысл? Если отлично работает цикл.
Индексы есть конечно. Но 30 секунд это для меня уже самоубийство. Гораздо меньше хватает, чтобы все легло.

Зависит от того, что нужно. :)
Если "для души", то можно и покопаться.

Да ничего там не ляжет. И не должно. 30 сек это на чтение и обработку, как бы.
Я тут для интереса попытал малость...
У меня на движок (буфер) отдано 2Г, таблица 27М записей, 4Г размером.
Запрос

select * from table
limit 10000000, 20

после запуска движка (т.е. идёт чтение данных с диска): 46 сек, процесс mysqld.exe "берёт" 1.7Г
второй раз (т.е. все данные в буфере): 7.8 сек, 1.7Г
Т.е. из буффера читается в 5+ раз быстрее. И, я так понимаю, ограничение идёт уже по нагрузке проца - хрень однопоточная и берёт 100% нагрузки одного ядра.

S.Chushkin

Ну вот именно) Для души полно другой работы. А это называется работать, чтобы наработаться. Если есть вариант сделать быстро и безболезненно, то плевать на предрассудки. Не всегда запрос в цикле, это плохо.

Для меня это много.

Почему?

Потому что данные в таблицах обновляются ежесекундно. Я не проверял, но думаю, что кэш тут не сработает. Если пересчитывать онлайн, 40 секунд на генерацию страницы - много.

Специфика работы такова, что статистика пересчитывается не вся сразу, а для каждого пользователя индивидуально. Всего их около 10 000.

Если так же по крону без цикла, то придется собирать все строки в один запрос. Апдейт вообще жутко долгий, база ложится. Не говоря уже про память.

А тут я не понял - при чём тут обновления в исходных таблицах и расчёт агрегированных данных? Например, по норме расчёт агрегированных данных для почасовой статистики должен делаться раз в час, а исходные данные пусть меняются хоть 1000 раз в секунду.
И надеюсь, ты не путаешь кеш на результаты запросов и буфер в InnoDB (innodb_buffer_pool_size). Буфер используется для работы с БД в RAM, а не на диске. При этом, надеюсь, innodb_flush_log_at_trx_commit в 2 установлен, чтобы буфер не сбрасывался на диск при каждом запросе.
Если же ты подразумевал, чтобы рассчитывать статистику каждый раз (при просмотре), то тут уж ... только если "сам себе злобный буратино" Хотя, кто его знает - бывает, что заказчики хотят и такое.

Этого я не понял. Почему нельзя просчитать всех сразу? Что там такого специфичного, что нельзя в запросе посчитать. 10000 это всего юзеров или всего за один расчёт?
У меня, например, агрегатная статистика вообще просчитывается в реальном времени, при каждой генерации страницы. Это 2 из ~20 запросов на каждую страницу при времени генерации страницы < 0.1 сек. Конечно, большая часть SELECT берётся из кеша. UPDATE кеш не пользует, естественно. Всего на запросы уходит < 0.02 сек (без кеша - ~0.05).

Так всё-таки, сколько записей (реально) у тебя изменяются? (всего за расчёт, который у тебя, как я понял, раз в час делается) И сколько записей (реально!) обрабатывается? (т.е. считывается, по которым идёт расчёт, а не те, что всего в таблице)

S.Chushkin
Долго объяснять. Вкратце. Основная таблица (самая большая) собирает основную статистику. Есть несколько других, где другие данные. Для каждого пользователя (а их 10000) на основе этих данных расчитывается индивидуальная статистика. Она складывается в сводную таблицу. Вот она и апдейтится. Если это делать онлайн (при посещении страницы), то скрипт работает очень долго на выборке и пересчете. Такое время генерации страницы недопустимо.

Если пересчитывать по очереди, как у меня, но апдейтить сразу скопом, то лочится сводная таблица и вообще никто никуда зайти не может. Вот и приходится апдейтить её партиями. Соответственно в цикле.

Там еще есть несколько нюансов, всего не могу рассказать. Вобщем забей. Цикл тут все равно самое оптимальное решение.