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

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

При выполнении сабжевых запросов MySQL сам выбирает подходящий индекс. Но если тому же самому запросу для той же самой таблицы указать тот же самый индекс (USE INDEX), то запрос начинает выполняться в 1,5-3 раза быстрее. Сейчас столкнулся с простым запросом (используется JOIN собственной таблицы), который после явного указания того же самого индекса начинает выполняться в 17 раз быстрее (с 0.0650 до 0.0037 сек). Я в ужасе. Получается, что MySQL ОЧЕНЬ много времени тратит на выбор нужного индекса?

А вы что, думаете они в файл набиваются? Сказано «создается временная таблица», но разве сказано, что она именно в файле создается. Есть движок таблиц Memory в MySQL, который как раз и создает таблицу в оперативке. Разве можно в данном случае сказать, что таблица не создается?

Дело в том, что прежде чем получить данные из связанных таблиц, эти данные должны набиться во временную таблицу. Тогда целесообразно обеспечить набивку этих данных гарантированно в оперативку. На вскидку не назовёте соответствующую настройку (настройки) MySQL?

Мегаподробно не расскажу. Сам не все знаю. Но идеи есть. Дело в том, что прежде чем получить данные из связанных таблиц, эти данные должны набиться во временную таблицу. Это нормально и логично. Statistics в данном случае — это сбор результирующих данных (то есть сколько всего строк получится, какие соответствуют условиям и т.п.). Нет ведь смысла во временную таблицу копировать вообще все. Нужно только то, что соответствует логике. Собственно, вот тут и важны индексы, так как если индексов не будет, то СУБД придется читать полностью файлы указанных таблиц, чтобы собрать всю статистику. Это и есть самая затратная часть в запросах из более чем одной таблицы. А когда результирующие данные в наличии и во временной таблице, тогда окончательную выборку сделать на составляет труда и не занимает времени.

Большой statistics, возможно, из-за низких значений некоторых настроек MySQL, связанных с памятью (не совсем понимаю фразу the server is probably disk-bound performing other work из справки) А может быть, причина в ограничении скорости операций чтения на VPS?

Николай, не могли бы вы прокомментировать вот этот профайлинг. Запрос — как в сабже (условия по тем же полям — TV и значение), но сами условия немного сложнее (результат выборки — 150 записей). starting 0.000011 checking query cache for query 0.000101 Opening tables 0.000010 System lock 0.000004 Table lock 0.000027 init 0.000037 optimizing 0.000020 statistics 0.018192 preparing 0.000032 Creating tmp table 0.000029 executing 0.000002 Copying to tmp table 0.011076 Sending data 0.000065 end 0.000002 removing tmp table 0.000006 end 0.000003 query end 0.000003 freeing items 0.000210 storing result in query cache 0.000008 logging slow query 0.000002 cleaning up 0.000003 Практически всё время съедают statistics и Copying to tmp table. Большой statistics, возможно, из-за низких значений некоторых настроек MySQL, связанных с памятью (не совсем понимаю фразу the server is probably disk-bound performing other work из справки) А Copying to tmp table — не понятно, на диск или в оперативку… P.S. Именно сабжевый запрос даёт аналогичный профайлинг, но Copying to tmp table в процентном соотношении занимает не так много времени, но statistics по-прежнему высокий.

Да, и у меня это в расписании есть. Но что-то дела основные загрузили, так что приходится сдвигать это. Видите же, вообще практически ничего не пишу :) Как только освобожусь (а это скорее всего только в начале августа), так сразу напишу.

Здравствуйте, Николай! Вы как-то писали о том, что планируете написать статью о создании крупного высокопосещаемого новостного портала на МОДХ Рево. Мы все ждём. :) Я по крайней мере точно жду. :)