Jump to content

Связанный подзапрос

В SQL к базе данных запросе ( коррелированный подзапрос также известный как синхронизированный подзапрос ) — это подзапрос (запрос, вложенный в другой запрос), который использует значения из внешнего запроса. Поскольку подзапрос может оцениваться один раз для каждой строки, обработанной внешним запросом, он может работать медленно.

Связанные подзапросы в предложении WHERE

[ редактировать ]

Вот пример типичного коррелированного подзапроса. В этом примере цель — найти всех сотрудников, чья зарплата выше средней по отделу.

 SELECT employee_number, name
   FROM employees emp
  WHERE salary > (
        SELECT AVG(salary)
          FROM employees
         WHERE department = emp.department);

В приведенном выше запросе внешний запрос

 SELECT employee_number, name
   FROM employees emp
  WHERE salary > ...

и внутренний запрос (коррелированный подзапрос)

 SELECT AVG(salary)
   FROM employees
  WHERE department = emp.department

В приведенном выше вложенном запросе внутренний запрос необходимо выполнить повторно для каждого сотрудника. (Достаточно умная реализация может кэшировать результат внутреннего запроса для каждого отдела, но даже в лучшем случае внутренний запрос должен выполняться один раз для каждого отдела.)

Связанные подзапросы в предложении SELECT

[ редактировать ]

Связанные подзапросы могут появляться где угодно, кроме предложения WHERE ; например, этот запрос использует коррелированный подзапрос в предложении SELECT для печати всего списка сотрудников вместе со средней зарплатой для каждого отдела сотрудника. Опять же, поскольку подзапрос коррелирует со столбцом внешнего запроса, его необходимо выполнить повторно для каждой строки результата. [ нужна ссылка ]

 SELECT employee_number,
        name,
        (SELECT AVG(salary) 
           FROM employees
          WHERE department = emp.department) AS department_average
   FROM employees emp

Связанные подзапросы в предложении FROM

[ редактировать ]

Обычно бессмысленно иметь коррелированный подзапрос в предложении FROM, поскольку таблица в предложении FROM необходима для оценки внешнего запроса, но коррелированный подзапрос в предложении FROM не может быть вычислен до того, как будет вычислен внешний запрос, что приводит к ошибке проблема курицы и яйца . В частности, MariaDB указывает это как ограничение в своей документации. [ 1 ]

Однако в некоторых системах баз данных разрешено использовать коррелированные подзапросы при объединении в предложении FROM, ссылаясь на таблицы, перечисленные перед объединением, с использованием указанного ключевого слова, создавая несколько строк в коррелированном подзапросе и присоединяя его к таблице в левый. Например, в PostgreSQL добавление ключевого слова LATERAL перед правым подзапросом: [ 2 ] или в Microsoft SQL Server , используя ключевое слово CROSS APPLY или OUTER APPLY вместо JOIN. [ 3 ] достигает эффекта.

Вычисление коррелированных подзапросов

[ редактировать ]

Обычно используемый вычислительный метод для коррелированного подзапроса — переписать его в эквивалентный плоский запрос. [ 4 ] (процесс, известный как сглаживание [ 5 ] [ 6 ] [ 7 ] [ 8 ] ). Преимуществом разработки алгоритмов в этом направлении является низкая сложность. Поскольку это индивидуальный подход, существующие системы баз данных не могут сглаживать произвольные коррелированные подзапросы, следуя определенным общим правилам. Кроме того, этот подход требует больших инженерных усилий для реализации алгоритмов выравнивания в ядре базы данных. Общий вычислительный подход заключается в непосредственном выполнении вложенного цикла путем итерации всех кортежей коррелированных столбцов из блока внешнего запроса и выполнения подзапроса столько раз, сколько кортежей внешнего цикла. [ 9 ] Этот простой подход имеет преимущество универсальности, поскольку на него не влияет тип коррелирующих операторов или структуры подзапросов. Однако он имеет высокую вычислительную сложность. Подход с ускорением на графическом процессоре используется для значительного повышения производительности вложенного метода высокой алгоритмической сложности за счет использования массового параллелизма и локальности памяти устройства на графическом процессоре. [ 10 ] который достигает цели как для разработки и реализации программного обеспечения общего назначения, так и для высокой производительности при обработке подзапросов.

  1. ^ «Ограничения подзапроса» . База знаний MariaDB . Проверено 24 декабря 2020 г.
  2. ^ «Табличные выражения — БОКОВЫЕ подзапросы» . postgresql.org . Проверено 21 января 2023 г.
  3. ^ «Предложение FROM плюс JOIN, APPLY, PIVOT (Transact-SQL)» . docs.microsoft.com . 01.06.2019 . Проверено 24 декабря 2020 г.
  4. ^ Ким, Вон (сентябрь 1982 г.). «Об оптимизации SQL-подобного вложенного запроса» . Транзакции ACM в системах баз данных . 7 (3): 443–469. дои : 10.1145/319732.319745 . S2CID   4374300 .
  5. ^ «Обзор оптимизатора запросов SQLite — 11. Сведение подзапросов» . SQLite . Проверено 21 января 2023 г. Когда подзапрос встречается в предложении FROM оператора SELECT, самое простое поведение — это преобразовать подзапрос в временную таблицу, а затем запустить внешний SELECT для временной таблицы. Такой план может быть неоптимальным, поскольку временная таблица не будет иметь никаких индексов, а внешний запрос (который, скорее всего, является соединением) будет вынужден выполнить полное сканирование временной таблицы. Чтобы решить эту проблему, SQLite пытается сгладить подзапросы в предложении FROM оператора SELECT. Это предполагает вставку предложения FROM подзапроса в предложение FROM внешнего запроса и переписывание выражений во внешнем запросе, которые ссылаются на набор результатов подзапроса. ...
  6. ^ «Сведение подзапросов FROM» . Вертика . Проверено 21 января 2023 г. Подзапросы предложения FROM всегда оцениваются перед содержащим их запросом. В некоторых случаях оптимизатор выравнивает подзапросы предложения FROM, чтобы запрос мог выполняться более эффективно.
  7. ^ «Преобразование подзапроса в обычное соединение» . Апач Дерби . Проверено 21 января 2023 г. Операторы, включающие такие подзапросы, могут быть объединены в объединения только в том случае, если подзапрос не вводит дубликаты в набор результатов...
  8. ^ «Глава 15: Руководство по абстрактному плану запроса — сглаженные подзапросы» . Сибаза . Проверено 21 января 2023 г. Некоторые подзапросы можно объединить в соединения. ...
  9. ^ Селинджер, П. Гриффитс; Астрахань, ММ; Чемберлин, Д.Д.; Лори, РА; Прайс, Т.Г. (1979). Выбор пути доступа в системе управления реляционными базами данных (pdf) . Материалы Международной конференции ACM SIGMOD по управлению данными 1979 года, Бостон, Массачусетс . СИГМОД '79. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 23–34. дои : 10.1145/582095.582099 . ISBN  089791001X . 10.1145/582095.582099.
  10. ^ Флоратос, Софоклис; Сяо, Мэнбай; Ван, Хао; Го, Чэнсинь; Юань, Юань; Ли, Рубао; Чжан, Сяодун (2021). NestGPU: обработка вложенных запросов на графическом процессоре . 37-я Международная конференция IEEE по инженерии данных. стр. 1008–1019.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: c6a387f6858b0b2899e48952b8ba219d__1724091540
URL1:https://arc.ask3.ru/arc/aa/c6/9d/c6a387f6858b0b2899e48952b8ba219d.html
Заголовок, (Title) документа по адресу, URL1:
Correlated subquery - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)