зависит от размера категории. на php нужно стараться по максимуму использовать встроенные функции, они же на Cи написаны. И не крутить циклов.
предложение iopiop прекрасно, но подразумевает вообще другой принцип листания и вообще его уже предлагали.
Посмотрели бы уже план. Скорее всего 11 категория самая большая и он решил перебрать всю таблицу.
Трава зеленая.
Андрейка - бот.
Да нет, настройки mysql.
Если вы видите в банкомате надпись "операция завершена", то при правильной настройке всей обрабатывающей цепочки , эта надпись означает ответ на commit. И что данные записались в надежное хранилище и никакая перезагрузка в том числе oom-killer ядра их уже не испортит.
Именно так спроектированы СУБД. И именно так работает mysql, даже если кто-то не считает mysql достойным банковского процессинга.
LEOnidUKG, ну не получается (c) :) Похоже нет способа даже в обычном C API не тащить на клиента все записи и пользоваться data_seek. А могла бы быть интересная возможность.
Тогда пусть будет обычный буферизированный запрос. А перекачивая данные вместе с data_seek вы избавляетесь от цикла по всему результату.
Количество всех записей вы узнаете "бесплатно" с помощью mysql_num_rows.
zexis, все не так страшно http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html. Любая программа может работать с диском без файловой системы не имея понятия о дорожках, цилиндрах - нужно просто открыть соответствующий файл устройства.
А то, что у Андрея mysql что-то теряет при перезагрузке, это уже вопрос правильной настройки.
не нужен никакой count.
еще раз идея :
у вас известен номер страницы $page, число документов на странице $per_page
1 Запускаете запрос на получение всех id постов по всей категории отсортированных в нужном порядке. Запрос небуферезированный. Он не выполняется, а результат его сразу берется из кеша.
2 Пропускаете $page*$per_page строк с помощью функции mysql_data_seek не мучая php 37710 итерациями, как раньше. На php никакие строки не поступают.
3 считываете $per_page следующих строк в цикле - вот это ваши id документов.
(3a тут же делаете mysql_free_result , чтобы максимально быстро снять блокировку чтения с кеша запросов)
4 запрашиваете все документы обычным запросом WHERE ID in (..).
LEOnidUKG, тогда смысла нет тащить и сортировать массив. просто в цикле отсчитайте нужную страницу.
или через mysql_data_seek отлистайте до нужной позиции = 25*страница.
Вместе с mysql_unbuffered_query будет вообще пушка.
Странно, что кеш mysql тут вообще помогает, ведь он должен сбрасываться при любых изменениях в таблице cms_freepages. Не особо широко применимое решение.
LEOnidUKG, но тогда вам удалось использовать кеш mysql и это можно назвать хорошим решением.
Все-таки, там именно тот код используется, что вы привели или другой ? Он ведь неверный и может выводить неправильные результаты.
Если это комментарии, то они из одной категории, отсортированы на каждой странице, но при листании страниц не отсортированы относительно этих страниц. Тянитолкай дело говорит.
LEOnidUKG, очистили кеши чего? mysql query cache или внутренние кеши сайта?
Если бы вы кешировали список ид по категориям и на основе этого кеша строили листалку страниц, то был бы толк.
Интересно было бы проверить как будет работать подобная листалка построенная на большом query_cache + mysql_unbuffered_query + mysql_data_seek. Эта связка может имитировать LIMIT без перекачивания к php всего списка идентификаторов в категории. Но вот кеш mysql очищается весь при любом изменении опорной таблицы. На практике скорее всего никто не использует подобное.
Salambo, как ты мог не нагуглить бесплатный, быстрый, кроссплатформенный и прекрасно автоматизируемый imagemagick ?
