LEOnidUKG

LEOnidUKG
Рейтинг
1776
Регистрация
25.11.2006
Должность
PHP
Интересы
Программирование

netwind, действительно поторопился с выводами. Сейчас кэши очистил, разницы в скорости не увидил, что мой код на PHP, что запрос в БД.

netwind:
ну а изначальный тогда что возвращает и сколько выполняется? не должен сильно отличаться

SELECT * FROM `cms_freepages` WHERE cat=2 ORDER id DESC LIMIT 37710, 30

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

А у меня:

1. Запрос: Отображает строки 0 - 29 ( 3,898 всего, запрос занял 0.1916 сек.) [id: 515 - 1203]

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

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

---------- Добавлено 24.02.2012 в 00:01 ----------

Создал виртуальный раздел в памяти и поместил БД туда. Скорость возрасла раз этак в 5-10 как минимум.

Ох было бы у меня памяти 32 ГБ, положил бы тоже туда, но увы, у меня на весь сервер 2 гб.

netwind:
Но это бред. Если у вас действительно есть индекс, то сервер не будет читать каждую запись и все ее поля.
Вот я напишу такой запрос согласно вашему предположению:

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 ;

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

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

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

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

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

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

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

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

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

В новом коде:

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

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

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

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

PROFIT!

Так изначально запрос тормозил по 2, а не по 14 категории. Как так ?

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

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

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

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

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

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

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

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

От 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 сек.)

самый простой способ

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

Видимо читали на сайтах хостеров

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

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

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

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

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

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

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

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

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

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

melkozaur:
vandamme,
А можно подробней? Ну например увели данные карты, но как они эти данные в банкомат вводят без собственно самой карты?

Значит ТС попал в очень весёлый банкомат, где и считыватель карты тоже был. Поэтому была возможность изготовить полную копию карты.

Всего: 31521