mysql любит запросы тех, кто понимает что он, mysql, делает. и все.
А у вас вообще результаты другие должны быть, судя по коду. Проверьте результаты на идентичность оригинальным и адекватность. ---------- Добавлено 23.02.2012 в 22:21 ----------
теперь видно, что первоначальный запрос даже быстрее запроса построенного по вашей теории?
ну а изначальный тогда что возвращает и сколько выполняется? не должен сильно отличаться
SELECT * FROM `cms_freepages` WHERE cat=2 ORDER id DESC LIMIT 37710, 30
Но это бред. Если у вас действительно есть индекс, то сервер не будет читать каждую запись и все ее поля. Где планы ? Где логи 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 даже попадания в кеш отделить от непопаданий.
Либо вы банально мерять не умеете.
Некоторые решения репликации могут разные БД накатывать параллельно. Так что выгоднее все же разные базы.
LEOnidUKG, я могу поверить, что это работает быстрее, но где логика? почему именно так ? У вас сервер для php намного быстрее mysql-ного ?
запросы на категории может закешировались полностью?
Так изначально запрос тормозил по 2, а не по 14 категории. Как так ? По-моему вы просто напутали и преждевременно обрадовались. Попробуйте именно по тем страницами походить, которые тормозили.
И чего добились? Где LIMIT потерялся ?
Но обязан. Что за ошибка? Это даже в старых версиях работало.
Ну или попытайтесь достать полный запрос хотя бы в логах.
Как правило, да. Разработчики тоже люди и тоже учатся на своих ошибках. Только дополнительные возможности движка не включайте на радостях.
А если сможете обновить mysql до 5.6, то сможете безболезненно перейти на innodb. Причем у вас останутся работать индексы FULLTEXT, которые DLE любит использовать.
Если речь идет о выделенном собственном сервере, то innodb способен ускорить безнадежно плохие запросы за счет других ядер и своих свойств всасывать в память все данные и обходиться без обращения к ОС при переборе строк. myisam так не умеет.
edogs, значит одна из ваших голов так поясняет, что ничего не понятно. По крайней мере самый простой способ в вашем изложении выглядит глупым. От остальных способов будет толк.---------- Добавлено 23.02.2012 в 19:01 ----------
ну вот, уже отказались от первого варианта. и кто тут еще троллит?
ну так поищи в тексте php "SELECT id, autor, date, short_story, SUBSTRING(full_story, 1"
Но таких запросов в dle 9.2 я нашел штук 10, так что негоже так гадать.
Вместо mysqladmin, лучше запустить команду SHOW FULL PROCESSLIST - она вам покажет полный текст запроса. Тогда будет легче.
