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

На id какой индекс стоит?

Дык надо делать where id>37710 and id<37740, иначе будет сортировка и перебор всех записей

limit 37710 подразумевает просмотр 37710 записей, понятно что сервер это не радует.

самый простой способ - вынос из cms_freepages всех полей по которым не идет фильтрация, вплоть до того что оставить только id и cat, а все остальное сгрузить в таблицу отдельную. Тогда просмотр этих 37710 будет очень шустрым, а дальнейший выбор "недостающих" полей уже будет по ИД и будет мегашустрым. Это редко где делают и совершенно зря.

следующий по простоте способ, это делать пейджинацию с указанием ид. т.е. страница 2, ИД такой-то, тогда выборка будет cat=2 and id>67382 limit 0 (сверху ограничивать не надо), 10 вместо limit 37710,10 , где 67382 понятно последняя запись на предыдущей странице.

остальные способы суть есть вариации.

Видимо читали на сайтах хостеров:) Недаром советы увеличить по железу. По железу тоже бывает надо, но не в вашем случае.

У Вас всего 150000 записей. ИД наверняка INT (4 байта), кат скорее всего не шире SMALLINT (2 байта). 6 байт на строку если сделать мемори табличку. Это меньше мегабайта памяти. Если беспокоят тормоза только такой выборки, то для пейджинации идеально мемори-табличка с 2 полями. И всё будет просто страшно летать. Можно и не мемори в принципе, это мы так, увидев про недостаток памяти написали, на обычной таблице тоже летать будет:)

Вариант хороший, но нужно как-то продумать переиндексовку этого id, а то если запись удалить бла-бла-бла... или же делать добор.

---------- Добавлено 23.02.2012 в 20:06 ----------

Примари индекс

А explain что показывает?

З.Ы. вообще такое чувство что у вас на каком-то поле висит фултекст индекс

Не самый простой, это реорганизация CMS.

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

---------- Добавлено 23.02.2012 в 20:32 ----------

Нет, там просто тексты большие новостные. Ими всё забивается.

редко делают, потому что все освоили mysql 5, где можно сделать подзапрос обрабатывающий только id без остальных полей. Кстати, временные таблицы создаваемые при использовании подзапросов тоже в основном MEMORY и остальные фантазии неактуальны.

Не обязательно, вместо изменения таблицы cms_freepages, можно просто кэширующий слой сделать на базе таблицы cat/id с другим названием. Тогда достаточно будет изменения запроса в базу, но Вы же не надеялись совсем без изменений всё сделать?:)

Вы или в вопрос ТС не вникли или вообще не понимаете что говорите:)

edogs, или вы не вникли в mysql. подключайте вторую голову, она умнее.

Своим хамством Вы несомненно доказали свою правоту.

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

LEOnidUKG, у Вас по сути 2 основных варианта.

Тот что мы говорили первым - делать кэш для пагинации в виде отдельной таблицы id/cat - этот вариант следует выбрать если Вам критично важна возможность юзером вбить 50 страницу и попасть на нее.

Тот что мы говорили вторым - делать запрос вида id>67238 limit 10, т.е. пагинацию делать по сути по ИД - при пролистывании страниц подряд этот способ проще и быстрее, но вбить номер страницы и попасть куда надо уже не получится.