Здравствуйте.

Имеется таблица с полями id,datetime,field1,field2 и еще ряд полей с данными.
id - unsigned int, auto_increment, PRIMARY key
datetime - int
field1 - smallint
field2 - smallint
Создан составной индекс field1,field2,datetime BTREE. Также есть индекс datetime, тоже BTREE.

Делаю запрос



Проблема в том, что в часы пик десятки таких запросов висят минутами в процессах со статусом "Sorting result". MySQL при этом сжирает весь процессор.
При профилировании основное время запроса уходит на "Sorting result", достаточно много также на "Sending data".
EXPLAIN сообщает следующее:


Однако иногда бывает так:


Второй вариант наблюдается всегда, когда не используется LIMIT, но по-моему и с LIMIT иногда бывает так.

В таблице порядка 130 тыс. строк. MyISAM.
MySQL версии 5.5.21. Windows Server 2008. VDS от 1GB, максимальный тариф (4096 МБ памяти, 4 ядра по 2 ГГц).
Настройки уже покрутил, все буферы выставлены в достаточно большие значения.

Сейчас посмотрел, время работы около 2 суток, число запросов 22М, т.е. в среднем 125 в секунду. Но запросы в основном идут только в рабочие дни, причем лишь порядка 12-14 часов в сутки, т.е. в часы пик скорость могла быть около 300 запросов в секунду. Странно, но по процессам я вроде бы такого количества не наблюдаю, проверю в понедельник. Однако, если статистика не ошибается, то может быть для такой нагрузки уже недостаточно этого железа?

Проблемой также является то, что таблица должна постоянно обновляться, старые данные удаляются, новые добавляются, поэтому кэширование неэффективно, однако кэш включен. Я уже сделал промежуточную таблицу, в которую складываю данные, а затем раз в 10 минут переношу их в основную таблицу запросом "INSERT INTO `table` SELECT * FROM `table_buf`". Удаление не проблема, оно делается раз в сутки, ночью, когда сервер без нагрузки.

Собственно вопрос, что можно сделать для ускорения?

Но desc индекс для числовых полей неактуален? Или я чего-то не знаю?
В частности запрос
ALTER TABLE `table` ADD INDEX `idxX` ( DESC `field` )
создаст индекс для field без ошибок и варнингов, но если сделать дамп структуры таблицы, то индекс там будет обычный, без desc.

Вариант с изменением порядка полей в индексе проверю в понедельник.

Cygapb-007 , при создании составного индекса, desc затем также не фигурирует в дампе структуры таблицы, т.е. все выглядит так, как будто desc просто игнорируется. Но, в любом случае, спасибо за идею, я попробую создать индекс в другом порядке и с desc.

ScareCrow , как я понимаю, MySQL и сам выбирает индекс именно по datetime, но возможно не всегда, я попробую указывать его принудительно, спасибо за идею.

По результатам отпишусь, ну и конечно буду рад новым идеям :)

Похоже, что "USE INDEX (datetime)" решило проблему. В общем-то сейчас вижу, что этот вариант был на поверхности, но тогда казалось, что я в полном тупике.
Кстати, я пробовал создать индекс по datetime и с DESC и без, но результат был одинаков.
Спасибо всем за идеи.