mysql+150000 записей+размер 500МБ. Вешается :)

Да оно уже сейчас выполняется доли секунды. Опять же говорю сейчас проблема лишь как быстро считать все ID из категории 1 раз и всё.

АА :) чета я пропустил сообщение что проблема решена :)

Вот тут решение проблемы: /ru/forum/comment/10080098

не нужен никакой 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 (..).

ввести такое?

Ну мы тем самым лишь уменьшаем сам массив, это опять же доли секунды.

---------- Добавлено 24.02.2012 в 03:33 ----------

Да конечно.

1.Из мануала, Замечание:

Однако, плюсы использования mysql_unbuffered_query() имеют свою цену: вы не можете использовать функции mysql_num_rows() и mysql_data_seek() с результатом запроса, возвращённым этой функцией, пока не будут получены все ряды. Кроме того, вы должны будете обработать все ряды запроса до отправки нового запроса, используя тот же link_identifier.

2. Если мы даже применим mysql_data_seek, то нам НУЖНО количество ВСЕХ записей для составления листинга.

LEOnidUKG, ну не получается (c) :) Похоже нет способа даже в обычном C API не тащить на клиента все записи и пользоваться data_seek. А могла бы быть интересная возможность.

Тогда пусть будет обычный буферизированный запрос. А перекачивая данные вместе с data_seek вы избавляетесь от цикла по всему результату.

Количество всех записей вы узнаете "бесплатно" с помощью mysql_num_rows.

LEOnidUKG

попробуйте использовать < и > (или BETWEEN) вместо IN

по-идее это быстрее если используется индекс

И составной индекс на cat asc, id asc и в пхп по массиву ходить с конца в начало. ходить по массиву с конца в любом случае лучше сделать тк mysql не умеет хранить индекс в обратном порядке

кстати, вы не рассматривали вариант с передачей параметра типа where cat=2 and id > ... limit 25 ?

5 страниц рассуждений о сферическом коне в вакууме

netwind,iopiop, да это опять доли секунды. Тут главное быстро собрать все ID категории и всё.

Fearful, конечно профессор, шли бы только мимо :)

последний вариант который я вам предложил пробовали ? И все id собирать не надо, и серверу перебирать все записи не надо