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

edogs, значит одна из ваших голов так поясняет, что ничего не понятно. По крайней мере самый простой способ в вашем изложении выглядит глупым. От остальных способов будет толк.

---------- Добавлено 23.02.2012 в 19:01 ----------

ну вот, уже отказались от первого варианта. и кто тут еще троллит?

От WHERE id сразу отказываемся т.к. у нас есть поле cat, по которому идёт выборка. Поэтому там не угадать какие id будут в ней.

---------- Добавлено 23.02.2012 в 21:09 ----------

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

---------- Добавлено 23.02.2012 в 21:23 ----------

Сделал что-то типо такого:

$result=mysql_query("SELECT id FROM `cms_freepages` WHERE cat=14");

while ($rowclubs = @mysql_fetch_array($result))

{

$arrayid[]=$rowclubs['id'];

}

$cnt=sizeof($arrayid);

$newmass=array_chunk(array_reverse($arrayid),25);

echo 'SELECT * FROM `cms_freepages` WHERE id in ('.implode(',',$newmass[11]).') ORDER BY ID';

Отображает строки 0 - 24 ( 25 всего, запрос занял 0.1117 сек.)

И чего добились? Где LIMIT потерялся ?

Ну же всё практически залетало.

---------- Добавлено 23.02.2012 в 21:42 ----------

Зачем он нам? Спарсили все ID это моментально. А потом уже в коде разбили на страницы.

Вообще первый запрос идёт именно на количество. Фишка в том, что ВООБЩЕ от LIMIT избавились.

---------- Добавлено 23.02.2012 в 21:47 ----------

Да всё! Теперь можно любую страницу перейти усё летает.

Так изначально запрос тормозил по 2, а не по 14 категории. Как так ? По-моему вы просто напутали и преждевременно обрадовались. Попробуйте именно по тем страницами походить, которые тормозили.

У меня 19 категорий и ч0? По каждой идёт сортировка такая. Чёт вы не туда вообще въехали :)

LEOnidUKG, я могу поверить, что это работает быстрее, но где логика? почему именно так ? У вас сервер для php намного быстрее mysql-ного ?

запросы на категории может закешировались полностью?

Вы код наверное не поняли :)

В старом коде:

1. Мы узнавали количество всех записей в категории

2. Высчитывали какой лимит нам надо, чтобы было по 25 записей на 1 странице

3. Составляли запрос с количеством LIMIT

Получается, что сервер перебирал все записи из таблицы, а они ТОЛСТЫЕ и большие, выбирал нужное количество и пыхтя выдавал нам.

В новом коде:

1. Мы составляем список всех ID в категории, не затрагивая тексты. Учитывая, что id это PRIMARY индекс, всё выполняется моментально

2. Быстро считаем количество записей в массиве и режим его по 25 штучек

3. Составляем запрос, в котором запрашиваем точные ID материала, которые нам нужны.

Наша база не напрягаясь выдаём нам точные, найденные опять же по PRIMARY индекс нужные записи и отдаёт нам :)

PROFIT!

Но это бред. Если у вас действительно есть индекс, то сервер не будет читать каждую запись и все ее поля. Где планы ? Где логи slow log ?

Вот я напишу такой запрос согласно вашему предположению:

select * from `cms_freepages`,

(SELECT id FROM `cms_freepages` WHERE cat=2 ORDER ID desc LIMIT 37710,30) sub

where `cms_freepages`.id=sub.id ;

Неужели в разы быстрее?

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

В сборках percona вы можете в slow log даже попадания в кеш отделить от непопаданий.

Либо вы банально мерять не умеете.

MySQL вернула пустой результат (т.е. ноль строк). ( запрос занял 4.2431 сек. )