Добрый день, уважаемые!

Прошу помочь разобраться в проблеме ОЧЕНЬ долгих запросов к бд на INSERT/UPDATE/SELECT.

авторQuery_time: 16.669909 Lock_time: 0.000034

Есть таблица, в которую в режиме реального времени вносятся данные о работе операторов CRM (или, скорее сказать, многопользовательской CMS):

id (PRIMARY) /* соответствует id пользователя */
lastopenid (INT(11)) /* последний id обработанной заявки */
lastopenmod (VARCHAR(50)) /* по сути, просто комментарий */
date (TIMESTAMP) /* время операции*/

Одновременно в таблице находятся не более 10 записей.

Алгоритм:
1. опреатор залогинился - вносим запись с его id
2. оператор обработал заявку - обновляем запись
3. оператор обработал заявку - обновляем запись
... и т.д.
N. оператор обработал заявку - обновляем запись
... оператор разлогинился - удаляем запись из таблицы.

Пример запроса:
авторINSERT DELAYED INTO ac_workstatus (id, lastopenid,lastopenmod) VALUES(649847,7,"ecovata/price")
ON DUPLICATE KEY UPDATE lastopenid=7, lastopenmod="ecovata/price";


Сама эта таблица вспомогательная, просто для фиксации действий, что позволило реализовать очень быструю выборку из больших таблиц.

Т.е. параллельно INSERT DELAYED - ON DUPLICATE KEY UPDATE идет постоянный SELECT ключей для других таблиц (тоже весьма медленный!):

автор# Query_time: 3.148636 Lock_time: 0.000048 Rows_sent: 1 Rows_examined: 1
SELECT lastopenid,lastopenmod AS mod FROM ac_workstatus WHERE id=649847;

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

AkinaС точки зрения происходящего таблица должна быть Engine=Memory. Это так?

нет, InnoDB.

AkinaССЗБ
Ясно:) Не популярно это, даже не знал чесно говоря...

AkinaС точки зрения происходящего таблица должна быть Engine=Memory. Это так?
После замены на MEMORY Engine и перезагрузки, приведенные запросы перестали сыпаться в лог slow_queryes.

Посмотрел load averages (top -SIt) - выросли, похоже MEMORY реально быстрее запросы выполняет.

Надеюсь - это выход, спасибо!