Помогите оптимизировать этот запрос: 
среднее время выполнения: 0.005
Нужно данный запрос ускорить примерно до 0.002

Где может быть торможение.

P.S.
Я понимаю что все зависит от машины и типов данных - но что еще может тормозить в запросе. Может есть рекомендации как объединить например вложенные запросы (таблицы pn и pa - идентичны по структуре.

Это сообщение отредактировал(а) skyboy - 28.3.2009, 11:42

в mysql профайлинг(диагностика производительности) запроса делается так:

в результате выполнения ты узнаешь много интересных вещей(в том числе, что из-за order by rand() происходит создание временной таблицы или что подзапрос тоже дает временную таблицу, возможно - ещё и с сортировкой из-за union).
вот выполни и выложи результат здесь.
потому что реальные данные только и тебя.
и мы, глядя только на запрос, можем посоветовать тебе не использовать order by rand(), а потом окажется, что у тебя, к примеру, в таблице `ca` три несчастных записи, зато в `pa` - 1.5 млн записей без нужного индекса и оптимизация по таблице `ca` ничего не даст.
Так что выполняй профайлинг и давай сюда результаты.

Добавлено через 57 секунд
когда будешь вставлять на форуме результаты SELECT, используй, пожалуйста, "цитату", а не "код".
Ты бы видел, как адски распирает форум от запросов в теге "код", если ты не используешь переводы строки...

Ок. Поставил на заметку.

Это сообщение отредактировал(а) ArNic - 23.12.2009, 10:19

Только железом, ИМХО.
Или менять архитектуру.
Если столь малое время выполенния является проблемой, видимо надо найти способ реже выполнять.
СУБД не обещают работы в рилтайме.

Это сообщение отредактировал(а) Zloxa - 23.12.2009, 16:23

пальцем в небо:



какой тип данных у поля cid?
если числовой то почему вы взяли его в опострафы - попахивает не явным преобразованием типов из varchar в integer.
может ли cid быть меньше 0?
если нет, то стоит попробывать использовать не условие по отрицанию, а cid > 0.

так же попробывать NOT IN заменить на NOT EXISTS, зависит от того на сколько много данных возвращает под запрос...

еще раз, все это предположения основанные на том что "одно место" чувствует что это может повлиять на скорость выполнения запроса.
в какую сторону сами увидите...