KravaДобрый день. Подскажите в чем проблема.
Вложенный запрос долго выполняется


А если разделить на 2 отдельных запроса тогда все быстро получается. В чем же тогда проблема ?

Akina,

DISTINCT подразумевает сортировку и группировку всех записей,
EXISTS -проверку наличия хотя бы одной удовлетворяющей условию записи, что гораздо экономнее

miksoftCygapb-007Akina,

DISTINCT подразумевает сортировку и группировку всех записей,
EXISTS -проверку наличия хотя бы одной удовлетворяющей условию записи, что гораздо экономнее Не надо столь категорично. Не факт.При наличии индекса - одна операция INDEX SEEK для каждой строки. И никакой сортировки и группировки. Так же никакого отбора всей кучи данных второй таблицы для каждой строки исходной.

Приведите пример, когда DISTINCT выполняется быстрее поиска по ключу, пожалуйста ?

AkinaCygapb-007DISTINCT подразумевает сортировку и группировку всех записей
Это неверно.
http://dev.mysql.com/doc/refman/5.5/en/distinct-optimization.html If you do not use columns from all tables named in a query, MySQL stops scanning any unused tables as soon as it finds the first match. In the following case, assuming that t1 is used before t2 (which you can check with EXPLAIN), MySQL stops reading from t2 (for any particular row in t1) when it finds the first row in t2:


Наш случай...Спасибо, не знал:) MS SQL по-другому:)
В таком случае запросы эквивалентны, хотя логика с DISTINCT представляется мне более... тяжеловесной, что ли. Зачем во FROM перечислять таблицы, не попадающие в выборку? Дело привычки, должно быть.

Да вот, кстати, и ссылка: Оптимизация SELECT DISTINCT

Точнее да, эквивалентны — кроме полных дубликатов выводимых полей. И значит, ТС должен принять решение, надо ему знать о такого рода дубликатах или нет :)

С другой стороны, это уже другая логика запроса:
select distinct ... from table where exists(...)

miksoft,

даже с учетом особенностей оптимизации distinct в MySQL, он все равно будет выполняться дольше select from where exists - хотя бы за счет поиска дублей в исходной таблице

Хотя при этом, возможно, вернет меньше строк :)

miksoftCygapb-007Akina,

DISTINCT подразумевает сортировку и группировку всех записей,
EXISTS -проверку наличия хотя бы одной удовлетворяющей условию записи, что гораздо экономнее Не надо столь категорично. Не факт.И согласен, с «гораздо» – погорячился по незнанию :)
Но экономичнее – все равно остается в силе. И эквивалентно – для конструкции select distinct from where exists :)

Конгратс

Не, все же выскажусь еще раз, подбивая итоги :) Хотя разница и ... микронная :), но вы уж звиняйте, я тоже не против бинго

Krava , если у вас в таблице podcat_biz нет повторяющихся podcat_biz.ID (а их, скорее всего, нет, потому как ID - скорее всего автонумератор ), то вариант

будет выполняться быстрее, чем
за счет отсутствия в плане выполнения запроса трех лишних операций для DISTINCT : сортировки (кластерного индекса по ID в этом случае недостаточно, так как указаны и другие поля) по полям pb.id, pb.name, pb.url , группировки по ним же, и отсеивания (отсутствующих) дублей. Хоть дублей и нет, но операции ИМХО должны быть в плане выполнения. Как-то сомневаюсь я, что оптимизатор сократит эти операции при выборе оптимального плана... Хотя если я не прав, и оптимизатор MySQL умнее, чем я о нем думаю, то запросы идентичны, и мои шансы на бинго - 50:50, то есть уже проиграл
(Кстати, как проверить в плане выполнения наличие этих операций или их отсутствие? Или это только для MySQL Enterprise доступно? Я про что-то типа QueryAnalizer...)

Если же дубли есть и их нужно отбраковать при отображении, то вариант без EXISTS по плану выполнения запроса эквивалентен следующему:

и снова 50:50 :)