Как работает Exists?

Question

[UNy]

Уже бошка едет от Exists. Есть такой запрос:

SELECT *
FROM authors
WHERE EXISTS (SELECT * FROM m2m_books_authors 
                  WHERE authors.a_id=m2m_books_authors.a_id)

Ясно что он выведет всё из таблицы авторы где authors.a_id=m2m_books_authors.a_id.
Меня подробно интересует как это всё будет работать. Я представляю так :
Берем запись из authors в exists смотрим есть ли в нем запись с таким же id как и id authors, если есть возвращаем true и вуаля запись помещается в основную выборку.
Если я не прав пожалуйста опишите детально процесс взаимодействия запроса и подзапроса в Exists.

Answer 1

[UNy]

В общем нашел подробное объяснение тут https://stackoverflow.com/questions/5846882/how-do...

Если по русски: для строки из внешнего запроса проверяется существует ли строка в подзапросе, которая соответствует условию( в подзапросе). Когда найдется подходящая строка условие where exists будет удовлетворено для это строки и строка попадет в основную выборку.
Подзапрос выполняется для каждой строки таблицы внешнего запроса.

Answer 2

[ApeCoder]

Я думаю, это зависит от того, какие индексы и какая статистика есть по таблицам. Задача аналогична алгоритмам соединения

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

Какой конкретно алгоритм выбран, покажет команда EXPLAIN или инструмент Visual Explain в MYSQL Workbench

Comments

[UNy]

Мне нужно понять как Exists работает внутри

[ApeCoder]

UNy, explain покажет

[UNy]

ApeCoder, он показывает что в primary задействовано 7 записей( т.е все записи которые у меня есть в authors), а вот в подзапросе только 1. Мне нужно объяснение почему 1.

[ApeCoder]

Вы можете посмотреть выхлоп запостить сюда?

[UNy]

ApeCoder,

[ApeCoder]

https://dev.mysql.com/doc/refman/8.0/en/explain-ou...

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

Попробуйте сгенерировать пример побольше и пересобрать статистику. Rows показывает оценочное количество записей

Answer 3

[d-stream]

Вероятнее всего планировщик сообразит и построит inner join, но не исключено что у него на это не хватит интеллекта и запрос будет тупить...
Посему будет гораздо честнее писать inner join

Comments

[UNy]

Читал что + exists в том что он не перебирает строки и значения в отличие от in т.е производительность в бд где больше миллиона записей будет во много раз лучше.

[d-stream]

UNy, in естественно тяжелее, но я говорю о фундаментальных основах типа inner join - что-то, а соединения - это наипервейшие точки оптимизации в планировании выполнения.

Притом у нормального планировщика собственно все три варианта построят один и тот же план выполнения (что для join, что для in, что для exists). Но если планировщик так себе - могут быть засады.