Заказ пунктом, позволенным в подвопросе
Есть ли какая-либо причина, почему или почему не Вы должны сделать 'заказ' в подвопросе?
8 ответов
Да: это не должно быть сделано, потому что он не имеет смысла концептуально.
Подзапрос будет использоваться в некоторых внешних запросах (в противном случае это было бы бессмысленно), и этот внешний запрос придется делать в любом случае, поэтому нет точек заказа подзапрос.
Это связано с тем, что результаты запроса в SQL не придут нет конкретного порядка, если вы не используете явный заказ. Итак, даже если вы использовали заказ в подзапросе, у вас нет никакой гарантии, что это повлияет на порядок результатов внешнего запроса; Так что это бессмысленно.
Это, конечно, может иметь значение в некоторых конкретных RDBMS из-за ее реализации, но это будет специально для реализации, а не то, что вы должны положиться.
Редактировать: , конечно, если вы используете верх или ограничить в подзапросе, вы будут необходимо использовать заказ. Но это не стандартное SQL в любом случае ...
Вы должны использовать его, если подзапрос использует какой-то предел / TOP .
SQL Server не позволит ему, если подзапрос не содержит TOP или для следующего времени для XML :
-- Fails
WITH q(id) AS
(
SELECT 1
UNION ALL
SELECT 2
)
SELECT *
FROM (
SELECT *
FROM q
ORDER BY
id DESC
) q2
-- Succeeds
WITH q(id) AS
(
SELECT 1
UNION ALL
SELECT 2
)
SELECT *
FROM (
SELECT TOP 1 *
FROM q
ORDER BY
id DESC
) q2
-- Succeeds, but ORDER BY is ignored
WITH q(id) AS
(
SELECT 1
UNION ALL
SELECT 2
)
SELECT *
FROM (
SELECT TOP 100 PERCENT *
FROM q
ORDER BY
id DESC
) q2
Вы Может сделать это, но я бы обычно не хотел бы.
Оптимизатор будет игнорировать его (или бросить ошибку?)
См. « промежуточная материальность » для некоторых использований.
Если вы не используете вершину, это не полезно, так как вы будете заказывать во внешнем запросе в любом случае
Вы можете сделать это, но я бы обычно не хотел бы.
Оптимизатор проигнорирует это (или бросить ошибку?)
См. « Промежуточная материализация « Для некоторых использований.
-121--3060802-В зависимости от размера подпросионат, он повлияет на производительность до степени варринга.
Приказ не должен иметь значение в подпросе, хотя. Вы должны быть в состоянии переместить заказ порцией на внешний запрос (который должен быть один возвращение конечных результатов).
Вы не должны его использовать. Согласно «Art of SQL», это фактически предотвращает выполнение оптимизатора различных оптимизаций, которые он мог сделать в противном случае, потому что это предрассудно преобразует данные.
Его следует использовать, если в подзапросе используется какой-либо параметр LIMIT / TOP .
SQL Server не разрешит его, если подзапрос не содержит предложения TOP или FOR XML :
-- Fails
WITH q(id) AS
(
SELECT 1
UNION ALL
SELECT 2
)
SELECT *
FROM (
SELECT *
FROM q
ORDER BY
id DESC
) q2
-- Succeeds
WITH q(id) AS
(
SELECT 1
UNION ALL
SELECT 2
)
SELECT *
FROM (
SELECT TOP 1 *
FROM q
ORDER BY
id DESC
) q2
-- Succeeds, but ORDER BY is ignored
WITH q(id) AS
(
SELECT 1
UNION ALL
SELECT 2
)
SELECT *
FROM (
SELECT TOP 100 PERCENT *
FROM q
ORDER BY
id DESC
) q2
Вы можете это сделать, но я обычно не буду этого делать, если вам не потребуется.
Оптимизатор проигнорирует его (или выдаст ошибку?)
Для получения дополнительной информации см. раздел « Промежуточная материализация ».
-121--3060802- Это абсолютно законно. Т.е. SELECT id FROM entries WHERE author_id IN (SELECT id FROM authors ORDER BY name DESC) , но обычно получаются те же результаты.
Нет порядка by недействителен в подзапросе, когда вы заинтересованы в подмножестве общих данных, следовательно, вам всегда нужен TOP (SQL Server). Там нет смысла, имеющего порядок без верхнего подзапроса, потому что общий заказ результатов обрабатывается внешним запросом.