Цитата(A5uKa @ 25.11.2010, 09:54  ) | | то есть только так ? |
это ничего не меняет. Джойн выполнится раньше аггрегации и "Остальные поля" будут отобраны так же - первые попавшиеся
если уходить от in к джойну, то както так:
| Код |
select `p2`.*
from (select `p1`.`dir`
from `products` as `p1`
where p2.`text` like '%текст%'
order by `p1`.`dir`
limit 1
) as `s`
,`products` AS `p2`
WHERE p1.dir=p2.dir and p2.`text` like '%текст%';
|
Здесь, в принципе, пофиг, использовать лимит или min, критерии отбора не позволят использоывать индекс.
Если бы можно было использовать индекс, limit, думаю/*уверен на 80%*/, был бы предпочтительнее min
Явных преимуществ использования джойн в место in - я не вижу. Иногда стоит попробовать, когда in дает не желательный план, может статься план с джойном будет более удовлетворителен - т.е. юзабилити такого подхода мне видится лишь в целях обмана оптимизатора.
В довесок размышления в слух:
Для реализации операции in может быть выполнен semi-join, алгоритм его реализации для конкретной платформы может отличаться от от алгоритма inner-join, что может дать преимущество тому или иному подходу. Однако, на практике, сколько я ни пытался получить разницу времени отклика превосходящую погрешность измерения при сопоставимых стоимостях планов - мне не удавалось. |