Почему более сложный запрос работает быстрее?

Question

[AlikDex]

В общем 2 таблицы. Нужно с 1 таблицы синхронизировать даты во вторую. Причем во второй записей гораздо больше чем в первой.

Решение в лоб:

UPDATE `videos_stats` SET `published_at`=(SELECT `published_at` FROM `videos` WHERE `videos`.`video_id`=`videos_stats`.`video_id`)

(Запрос занял 0.0431 сек.)
И это лобовое решение работает медленнее чем второе:

UPDATE `videos_stats` as `vs`
    LEFT JOIN (
        SELECT `video_id`, `published_at` FROM `videos`
    ) as `v`
    ON `v`.`video_id`=`vs`.`video_id`
SET `vs`.`published_at`=`v`.`published_at`

(Запрос занял 0.0281 сек.)
Собстна почему так? На пальцах если можно.

Answer 1

[D3lphi]

Потому что в первом случае, вы, фактически выполняете 2 запроса. При чем, данные из вложенного select'а сначала выгружаются в оперативную память, а уже потом подставляются, как новое значение для `published_at`. А во втором все делаете одним. JOIN сам по себе достаточно быстрый оператор.

Comments

[Антон Антон]

я бы даже сказал, что первый запрос - это запрос в цикле

[AlikDex]

Антон Антон: второй тоже ведь по циклу ходит. Основываюсь на статье: https://habrahabr.ru/post/44807/
Она хоть и древняя но не думаю что так уж алгоритмы поменялись.

[D3lphi]

Антон Антон: конечно. Вложенный селект будет выполняться снова и снова, пока СУБД "проходит" по строкам, которые нужно обновить. (Пояснение для ТС'а).

[D3lphi]

AlikDex: во время джоина таблицы, как бы склеиваются. SELECT внутри джоина во 2 запросе выполняется единожды. А затем, работа идет с объединенной таблицей.

[AlikDex]

Василий: вообще не работает )

[AlikDex]

D3lphi: Примерно понятно.
Вот еще вопрос. Может дело еще в буфере? Т.е. в первом запросе значения из таблицы дергаются постоянно, а во втором тоже дергаются, но для уникальных video_id, остальные берутся просто из буфера. в таблице `videos_stats` у одного видео несколько строчек ~шесть штук на 1 идентификатор.
(читаю ман =))

[D3lphi]

AlikDex: в первом таблица videos дергается постоянно. Во втором - лишь единожды.

[Антон Антон]

AlikDex: ну, даже в ой статье есть merge join, который вполне может работать для одинаково отсортированных таблиц, соединяя их за один проход, без цикла в цикле (nested loops).

[Антон Антон]

AlikDex: выполните explain для обоих запросов и все вопросы отпадут https://habrahabr.ru/post/31129/

[Антон Антон]

и еще https://habrahabr.ru/post/211022/