В которой последовательности запросы и подзапросы выполняются механизмом SQL?
Привет я сделал тест SQL и сомнительный/любопытный об одном вопросе:
В которой последовательности запросы и подзапросы выполняются механизмом SQL?
ответы были
- основной запрос-> sub запрос-> sub sub запрашивает и так далее
- sub sub запрос-> sub запрос-> главный запрос
- целый запрос интерпретируется когда-то
- Нет никакой фиксированной последовательности интерпретации, анализатор запроса принимает решение о мухе
Я choosed последний ответ (просто, если это - большинство надежных w.r.t. других). Теперь любопытство:
где я могу считать об этом и кратко каков механизм подо всем этим?
Спасибо.
5 ответов
Вариант 4 близок.
SQL является декларативным: вы говорите оптимизатору запросов, что вы хотите, и он разрабатывает наилучший (с учетом времени/"стоимости" и т.д.) способ сделать это. Это может варьироваться для внешне одинаковых запросов и таблиц в зависимости от статистики, распределения данных, количества строк, параллелизма и бог знает чего еще.
Это означает, что не существует фиксированного порядка. Но это не совсем "на лету"
Даже при одинаковых серверах, схемах, запросах и данных я видел, что планы выполнения отличаются
.Обычно это зависит от вашей СУБД, но ... я думаю, что второй ответ более правдоподобен. Простой запрос обычно не может быть вычислен без результатов подзапроса.
Если вы хотите что-нибудь почитать по этим темам, получите копию Inside SQL Server 2008: T-SQL Querying. Он состоит из двух отдельных глав, посвященных логической и физической обработке запросов в SQL Server.
Я думаю, что ответ 4 правильный. Есть несколько соображений:
тип подзапроса - коррелирован он или нет. Рассмотрим:
SELECT *
FROM t1
WHERE id IN (
SELECT id
FROM t2
)
Здесь подзапрос не коррелирует с внешним запросом. Если количество значений в t2.id невелико по сравнению с t1.id, то, вероятно, наиболее эффективно сначала выполнить подзапрос, сохранить результат в памяти, а затем просканировать t1 или индекс на t1.id, сопоставляя с кэшированными значениями.
Но если запрос:
SELECT *
FROM t1
WHERE id IN (
SELECT id
FROM t2
WHERE t2.type = t1.type
)
здесь подзапрос коррелирует - нет способа вычислить подзапрос, если не известен t1.type. Поскольку значение для t1.type может быть разным для каждой строки внешнего запроса, этот подзапрос может быть выполнен один раз для каждой строки внешнего запроса.
С другой стороны, РСУБД может быть действительно умной и понимать, что существует только несколько возможных значений для t2.type. В этом случае она может использовать подход, использованный для некоррелированного подзапроса, если сможет предположить, что стоимость выполнения подзапроса один раз будет дешевле, чем выполнение его для каждой строки.
Механизм SQL пытается оптимизировать порядок выполнения (под) запросов. Часть, принимающая решение об этом, называется оптимизатором запросов. Оптимизатор запросов знает, сколько строк в каждой таблице, какие таблицы имеют индексы и по каким полям. Он использует эту информацию, чтобы решить, какую часть выполнить в первую очередь.