MySQL вопрос к специалистам

Jeck, там структура таблиц немного другая, только все усложнит.

Я наоборот здесь пытался описать как можно кратко.

В принципе решение найдено, за это большое спасибо Dash, и всем остальным за участие.

SELECT `list`.`id`, `list`.`name` 
FROM `list` 
WHERE `list`.`id` IN 
    (SELECT `list_id` 
    FROM `param` 
    WHERE `type`='day' AND `value`=$param1 OR `type`='text' AND `value`=$param2
    GROUP BY `list_id` HAVING COUNT(`list_id`)=PARAM_COUNT)

где PARAM_COUNT заранее известно, в данном случае PARAM_COUNT=2

Проверил, на скорость оба варианта запросов: первый, который я написал в первом посту (модификация в 6 посту) и этот.

Результат противоположный, первый запрос выполняется в 100 раз быстрее!

Записей в таблице `list` - 27 000, в таблице `param` - 37 000

Шаманство с ключами не помогло.

Как думаете из-за чего такой результат?

Скорее всего MySQL как-то сам оптимизирует запросы и многочисленные JOIN одной и той же таблицы ни как не влияют на скорость запроса.

Потому что вложенные запросы в Mysql обрабатываются очень криво.

Jeck добавил 04.02.2008 в 20:41

Попробуйте сделать вложенный селект во временную таблицу и потом уже запрос через JOIN должно ускорится.

IN 

    (...)

IN и так медленнее простого OR работает, так ему ещё и нужно каждый раз запросы делать.

Есть замечательная команда EXPLAIN, которая прольет свет на то, что тормозит.

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

Вынес вложенный селект в отдельный запрос, вместо IN сделал OR, скоростть выполнения запроса примерно такая же как и с JOIN (первоначальный вариант запроса).

Т.е. действительно, тормоз был во вложенном селекте, учту это в дальнейшей жизни :)

В итоге время выполнения запроса осталось прежнее, но немного увеличилось время исполнения скрипта (PHP)

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

На счет кошек согласен :), но оригинальный запрос и таблицы намного больше приведенного примера и ни как не пересекаются с данной проблемой. Эти данные будут лишними..

Можно, конечно, сделать экспериментальную модель (прототип) приближенную к реальной, но нужно ли это, не хочется застревать на этой проблеме.

Jeck, сделал еще проще слил запрос в массив и объединил его через OR, использование временной таблицы тормозит запрос примерно в 2 раза.

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