Форум пользователей MySQL

mihim написал:

paulus, в EXPLAIN все красиво, но хоть убейте меня, скорость работы варианта с подзапросом выше в 3 раза. На 130 000 записей в vacancies и 25 городах -  0,07 против 0,19 сек В теории с подзапросом должно работать медленнее, но на практике всё иначе...

я в это верю :-) больше того, это вполне объяснимо.
в данном случае, подзапрос исполняется один раз, отсюда и выигрыш по времени исполнения. Оптимизатор считает подзапрос константным(его результаты не зависят от данных из внешнего запроса) и выполняет его один раз, а потом уже исполняет join.

Как раз Ваш, paulus, последний запрос, считает count на каждую выбранную строку из towns и explain к сожалению этого не покажет.  красивый explain - не залог оптимальной работы. :-)

Хм, avgsoft, объясните тогда, пожалуйста, чем отличается способ
«посчитать count(*) каждый раз для одного элемента по ключу» (без подзапроса)
от «посчитать count(*) один раз для всех элементов» (с подзапросом)?

«посчитать count(*) каждый раз для одного элемента по ключу» - позиционируемся по ключу на нужный узел, считаем.
«посчитать count(*) один раз для всех элементов» - читаем данные из индекса, для каждого узла считаем.
нужна вся таблица, то есть при любом варианте, нужны все данные, хранящиеся в индексе. в вариант "count(*) один раз" работы исполняется меньше.

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

ну не настолько мгновенная.
да и ещё один вариант: count(имя_поля) считает количество не-NULL значений в указанной колонке, в отличие от count(*) . это тоже может давать отставание по времени исполнения.