Sql 子查询中是否允许ORDERBY子句

是否有任何理由或为什么不应该在子查询中执行“order by”

如果子查询使用某种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

---

你可以，但我通常不会，除非你有需要

乐观主义者会忽略它或抛出错误

---

有关某些用法，请参阅。

根据子查询的大小，它将在不同程度上影响性能

---

但是，顺序在子查询中并不重要。您应该能够将Order By Party移动到外部查询，该查询应该是返回最终结果的查询。

是：不应该这样做，因为它在概念上没有意义

子查询将用于某些外部查询，否则它将毫无意义，而且外部查询无论如何都必须进行排序，因此对子查询进行排序没有意义

这是因为SQL中的查询结果不会以特定的顺序出现，除非使用显式顺序。因此，即使在子查询中使用了ORDER，也不能保证这会影响外部查询结果的顺序；所以这是毫无意义的

当然，由于它的实现，它可能会在某些特定的RDBMS中产生差异，但这将是特定于实现的，而不是您应该依赖的东西

---

编辑：当然，如果在子查询中使用TOP或LIMIT，则需要使用ORDER。但无论如何，这不是标准的SQL…

这是完全合法的。也就是说，从条目中选择id，其中作者id在SELECT id FROM AUTHERS ORDER BY name DESC中，但通常会得到相同的结果。

除非使用top，否则它不会有用，因为您将在外部查询中进行排序。

当您对整体数据的子集感兴趣时，子查询中的ORDER BY无效，因此，您始终需要顶级SQL Server。在子查询中使用ORDER BY而不使用TOP是没有意义的，因为结果的整体顺序由外部查询处理。

您不应该使用它。根据“SQL的艺术”，这实际上阻止了优化器执行它本来可以执行的各种优化，因为这会提前转换数据

聪明的人说这不是正确/有效的方法。 在我的例子中，选择子查询中的前100%解决了问题

---

通常干杯？你能给出结果不同的情况吗？如果你在你的子选择中添加一个限制语句，结果就会不同。在这种情况下，如果希望按姓名查看前5位作者的所有条目，则可以将subselect更改为SelectID from authors ORDER by name DESC LIMIT 5.True。对于TOP/LIMIT，它会产生影响，是必要的，有时甚至是必需的。否则，这没有什么区别。请注意，MySQL不支持按…排序。。。子查询中的限制。