Заказал прогон + составление описаний.
Все отлично, работой доволен.
Вынес вложенный селект в отдельный запрос, вместо IN сделал OR, скоростть выполнения запроса примерно такая же как и с JOIN (первоначальный вариант запроса).
Т.е. действительно, тормоз был во вложенном селекте, учту это в дальнейшей жизни :)
В итоге время выполнения запроса осталось прежнее, но немного увеличилось время исполнения скрипта (PHP)
Dash, с командой EXPLAIN так и не разобрался, как-нибудь потом на досуге попробую узнать как с ней работать.
На счет кошек согласен :), но оригинальный запрос и таблицы намного больше приведенного примера и ни как не пересекаются с данной проблемой. Эти данные будут лишними..
Можно, конечно, сделать экспериментальную модель (прототип) приближенную к реальной, но нужно ли это, не хочется застревать на этой проблеме.
Jeck, сделал еще проще слил запрос в массив и объединил его через OR, использование временной таблицы тормозит запрос примерно в 2 раза.
Выводы: первоначальный вариант запроса хоть и получается громоздким, но показал себя наиболее быстрым пока остановлюсь на нем.
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 одной и той же таблицы ни как не влияют на скорость запроса.
Jeck, хороший вариант, только в данном случае выберутся записи в которых присутствует хотя бы одно совпадение с параметром, аналогично:
WHERE p1.`type`='day' AND p1.`value`=$param1 OR p2.`type`='text' AND p2.`value`=$param2
а нужно
WHERE p1.`type`='day' AND p1.`value`=$param1 AND p2.`type`='text' AND p2.`value`=$param2
Dash, оператор GROUP BY `list_id` понравился, кажется нужно в этом направлении двигаться, пока только не понятно как.
А выражение value IN (...) будет пересекаться с другими типами параметров, некоторые параметры равны между собой, но соответствующие ($param1, $param2,...) не обязательно.
Т.е. если в таблице `param` есть записи (1, 'day', 23), (2, 'text', 23), и нужные параметры имеют значения $param1=23, $param2='seo', то запись выберется, хотя не соответствует желанному.
Каждый параметр имеет свой смысл, нужно чтоб значение соответствовало конкретному параметру, а не любому.
Наверно пример не совсем корректно представлен, немного подправил:
SELECT `list`.`id`, `list`.`name` FROM `list` LEFT JOIN `param` AS p1 ON (p1.`list_id`=`list`.`id`) LEFT JOIN `param` AS p2 ON (p2.`list_id`=`list`.`id`) WHERE p1.`type`='day' AND p1.`value`=$param1 AND p2.`type`='text' AND p2.`value`=$param2
Добавил к таблице `param` поле `type`, так думаю будет более понятней.
А насчет IN я тоже думал, но в данном случае это не подходит, вот если бы можно было использовать пары, что-то типа (`type`, `value`) IN (('day', $param1), ('type', $param2)), то это и было бы оптимальное решение, не знаю можно ли так?
Формировать циклом имеется ввиду, через другой язык (например PHP) ?
Если так, то это понятно, нужно как-то сам MySQL-запрос оптимизировать, а то он громоздкий получается.
В твоем примере не определены p1 ...
rrr-r@yandex.ru
Спасибо.
Я думаю навигацию (меню) от контента ПС в состоянии отличить, а текст скорее всего не целиком определяется на уникальность, а сравниваются пассажи по алгоритму ШИНГЛЫ.
Я пользуюсь хостингом от McHost, поддержка здравая, остальное на сайте.
Не "детское порно", а "доска детское порно".
Кстати, уже на 8 месте. Раскрутился :))
