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

вот можно ли както мускл заставить не делать лишнее - explain всегда показывает что будут выполняться все подзапросы.

ЗЫ
другие варианты



полагаю суть ясна.

ЗЫ если поможет, подзапросы корелированные (dependent subquery)

тоесть по типу
select * from target where target.field=value and

not exists(select * from t1 where t1.link = target.id) and
not exists (select * from t2 whre t2.link = target.id) and....

MasterZiv,

лучше бы подсказал, ответ , а не к словам придираться.

тем более что и вопрос связан именно с не понимание - что именно показывает эксплейн

=============
вот счас при оптимизации запроса вида

select * from t where t.t1 = @target
union
select * from t where t.t2 = @target
union
select * from t where t.t3 = @target

limit 10

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

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

ЗЫ(дополнительные условия в юнионе есть, но и учитывая их цифра с эксплейна не совпадает с реальностью, и при удалении всех остальных условий, тоже не совпадает)

нащот лимита при юнионе!
по документации - если хотите лимит и ордер бай для отдельного селекта поставте его в скобках с селектом

да и из практики - запросс выдаст не более 10 записей так как без скобок он относиться ко всему юниону!!!


нащот, почему юнион а не ИЛИ - прав человек, при юнионе используеться три индекса и вычисляеться пересечение

при ИЛИ - используеться только один.

или ваще долго работает, юнион быстрее но долго. оказалось легче делать три запроса к базе чем один с юнионом
(20 млн записей, юнион отрабатывает за 70-80 секунд при лимит 10.

этот запрос вообще делаеться в контексте апдейта

update table join (select union select union select limit 10)a on a.id=table.id
set ....

вообщем говоря, если по отдельности, то даже с лимитом 10000 апдейт срабатывает гораздо быстрее чем выборка с юнионом(пока индекс не кеширован - до 10 секунд, при кешированом ндексе - 2-3 секунды)


воопрос остаёться в силе, может кто сможет заставить мускл расматривать сразу три ситуации, и выдать быстро результат.

ЗЫ
хотя может стоит и остановиться на варианте выполнять их по отдеьности - ведь логика задачи гдето такова.
под труйную выборку будет попадать в 100 раз больше строк, чем надо за один раунд обновить.