отключить sql_calc_found_rows

Это запрос выборки постов для основного Цикла WordPress (по крайней мере очень-очень похож). Если его "отключить", то… фильм "Старик Хоттабыч" видели? помните, что случилось с самолетом, когда Хоттабыч сделал так, чтобы двигатели не шумели?

Резкое снижение скорости обработки запросов бывает связано с отключением индексов в таблицах. Проверьте в phpmyadmin.

А принципиально "исправить ситуацию" можно только одним способом – выбирать хостинг адекватный требования движка.

база стандартная вордпресовская
какие индексы проверить? на какие таблицы\поля?

Все индексы во всех таблицах. Должны быть цифры у кол-ва элементов и не должно быть надписей disabled

Подробности найдете в документации mysql и PMA и на специализированных форумах.

что такое индексы, как их ставить это понятно
не понятно, на какие поля и в каких таблицах нужно поставить индексы, чтобы ускорить тяжелые запросы

вот индексы в таблице posts

post_title нету, но в запросе это поле не фигурирует
индекс на поля post_type и post_status стоит, тогда почему медленно выполняется запрос?

не понятно, на какие поля и в каких таблицах нужно поставить индексы, чтобы ускорить тяжелые запросы

http://habrahabr.ru/post/31129/

почему медленно выполняется запрос?

Причин может быть вагон и маленькая тележка. Начиная от физического дефекта носителя и заканчивая особенностями настройки сервера.

Кстати, мне однажды удалось уменьшить время выполнения запроса в тысячу(!) раз простым обновлением mysql до последней актуальной версии.

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

что можно исправить?

Тот же запрос через PMA сколько выполняется? По идее должно быть от 0.1 до 10 ms.

Отображает строки 0 - 9 ( 10 всего, Запрос занял 0.0001 сек.)

Отображает строки 0 - 9 ( 10 всего, Запрос занял 0.0001 сек.)

Отличное время! Оставьте запрос в покое.

тогда почему этот же запрос отрабатывает из самого вордпресса за 8 секунд? и помещается в лог долгих запросов

Query_time: 8.242014

Хороший вопрос. Но боюсь, моих телепатических способностей не достаточно для диагностирования такого трабла. Такие проблемы и с полным (рутовым) доступом к "телу" не всегда удается победить. А я даже не знаю, на чем это всё у Вас крутится. Могу только предположить, что имеет место катастрофическая нехватка памяти у сервера, и процесс уходит в своп.

ну а если ткнуть пальцем в небо?
насколько я знаю, время выполнения запроса в пма нельзя принимать в расчет потому что там свои механизмы

Механизм там совершенно тот же самый – запрос к тому же самому демону mysqld. Остальное – влияние окружения, в т.ч. общей нагрузки на процессор, кол-во запросов, доступная память… всё влияет, и чем хилее сервер, тем больше взаимное влияние процессов.

Впрочем, можете поставить плагин http://wordpress.org/plugins/debug-bar/ (есть и другие) и посмотреть на время выполнения запросов в реальном движке. Чтобы долго не искали, как увидеть запросы, подскажу сразу: define( ‘SAVEQUERIES’, true ); в wp-config.php.

можно ли переписать запрос без Sql_calc_found_rows ? подозреваю именно изза него тормоза
может есть статьи как это сделать?

можно ли переписать запрос без Sql_calc_found_rows ?

Можно, с помощью подобного фрагмента:

function disable_sql_calc_found_rows( $query ) {
    if ( is_admin() || ! $query->is_main_query() )
        return;

    $query->set( 'no_found_rows', true );
}
add_action( 'pre_get_posts', 'disable_sql_calc_found_rows' );

Но при этом не будет работать постраничная навигация, для которой этот параметр и используется.