Как избавиться от временных таблиц

Если временные таблицы создаются в памяти, а не на диске, то в чём собственно проблема?

Смотря кому известный. Обычный блог для людей, который ведут люди в один момент не напишет 70000 постов и уж точно постарается улучшить и таксономию и вообще ресурсы к тому моменту когда он разрастется . Разработчики wordpress на это не рассчитывают. Они знают, что у вас сеошная помойка, презирают и делать ничего не будут.

Я бы попытался вытащить фильтр таксономии "наверх" и тогда основная выборка будет цепляться за индекс type_status_date. По крайней мере у меня цепляется, но где я возьму столько мусора в блоге?

Попробуйте у себя план и скорость вот на таком фокусе:

Но без экспериментальных данных ничего об выгоде и даже правильности этого запроса не скажешь. Кроме того, нужно же еще заставить wordpress собрать из кусочков именно такого вида запрос.

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

Формально запрос не избавляет от временной таблицы, но объем данных в ней сократится.

В целом, понятно почему кеширование так популярно. С этим просто ничего другого не сделать.

Скорее всего на диске.

Спасибо за советы, попробую эту категорию разделить на несколько, типа "название категории - архив за 2013г", "название категории - архив за 2014г"

надо только с запросом разобраться с помощью которого такое можно сделать,

вобщем я в этом не силён надо профи искать для того чтобы разбить категорию на несколько.

до 20000 постов в категории отрабатываются сервером нормально 0.02сек примерно, а вот всё что выше видимо лезет на диск и в результате тормоза.

Не надо тебе лезть в движок вордпресса. Просто настрой mysql, пример:

1. Создай виртуальный диск в памяти:

#shell> mkdir -p /mnt/ramdisk

#shell> chown mysql:mysql /mnt/ramdisk

#shell> mount -t tmpfs -o size=1024M tmpfs /mnt/ramdisk

2. Пропиши в конфиге mysql (/etc/my.cnf):

tmpdir=/mnt/ramdisk

3. service mysqld restart

Это всё.

Это все, что обычно могут предложить.

Но такие временные таблицы в плане- в любом случае плохой показатель. Хоть на диске, хоть в tmpfs. Хорошо бы от них совсем избавиться.

Использовать tmpfs для tmpdir, конечно, стоит, если еще не используется.

Тебе же написали, Wordpress. Что ты предлагаешь, ковыряться там? Смысл тогда в wordpress'e?

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

Вобщем запрос вот так сделал

запрос занял 0.0551 сек (вполне приемлемо)

id select_type table type possible_keys key key_len ref rows Extra

1 SIMPLE wp_term_taxonomy const PRIMARY,term_id_taxonomy,taxonomy term_id_taxonomy 44 const,const 1

1 SIMPLE wp_posts index NULL date_id 11 NULL 10150 Using index

1 SIMPLE wp_term_relationships eq_ref PRIMARY,term_taxonomy_id PRIMARY 5 site.wp_posts.ID,const 1 Using index

и никаких темпорари

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

надо что то типа?

function sql($wp_query){

if (is_category()){

$wp_query->sql('sql');}}

add_filter('pre_get_posts','sql');

насколько я знаю с помощью pre_get_posts можно изменить только хвост запроса

Vin_cent, на моём вдс к сожалению ramdisk не сделать

А когда выйдет очередное обновление wordpress, опять пойдёшь искать-править-код там? Допиливать wordpress, имхо, глупая затея.

я его и не обновляю, у меня по сути это уже и не вордпресс, там 70% кода переписано, если бы у меня стоял вордпресс не кастомизированный, этот сайт с 300000 постов на впске даже не запустился, с морды всего 5 запросов на базу, в то время как у неоптимизированного вордпресса от 20 и выше, к тому же я не использую html кеш, потому как динамика на страницах нужна.

вобщем осталось только два проблемных запроса этот и like, скорее всего fulltext придётся делать.