SQL标准规定子查询不能含ORDER BY，因其返回无序集合；仅当配合LIMIT/TOP/FETCH时才允许，用于确定截取行而非保证顺序，否则优化器丢弃或报错。
子查询里写 ORDER BY 直接报错，不是 bug 是标准
SQL 标准把表定义为数学集合，不带顺序；子查询只是提供中间数据集，ORDER BY 对上层无意义，优化器会直接丢弃。PostgreSQL 和 SQL Server 显式报错：ERROR: ORDER BY in subquery is not allowed unless it is accompanied by LIMIT or OFFSET、The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries。MySQL 5.7 静默忽略，8.0+ 默认也报错——这不是数据库实现差异，而是标准强制行为。
只有带 LIMIT / FETCH / TOP 的派生表才允许 ORDER BY
此时 ORDER BY 不是为了“让结果有序”，而是为截取服务：决定哪几行被选中。它只在特定上下文生效：
-
SELECT * FROM (SELECT id FROM t ORDER BY created_at DESC LIMIT 1) s——ORDER BY决定哪条是“最新” -
SELECT TOP 5 * FROM (SELECT * FROM logs ORDER BY time DESC) t（SQL Server）——内层ORDER BY是TOP语义必需的 -
SELECT * FROM t ORDER BY id OFFSET 0 ROWS FETCH FIRST 10 ROWS ONLY——FETCH要求前置ORDER BY
注意：一旦该派生表参与 JOIN 或被用作 IN 子查询，外层再加 ORDER BY 才真正控制最终输出顺序。
想按聚合结果排序？聚合放子查询，ORDER BY 留外层
常见错误是把 ORDER BY 塞进含 GROUP BY 的子查询里，比如：
SELECT * FROM (SELECT user_id, COUNT(*) c FROM orders GROUP BY user_id ORDER BY c DESC) t
这在 PostgreSQL 和 MySQL 8.0+ 直接语法报错。正确链路是：
- 子查询只做聚合计算：
SELECT user_id, COUNT(*) AS cnt FROM orders GROUP BY user_id - 外层查这个结果并排序：
SELECT * FROM (...) t ORDER BY t.cnt DESC - 若需动态权重（如订单数 × 0.4 + 平均金额 × 0.5），同样在外层
ORDER BY中组合，避免重复计算
别在 ORDER BY 里写 COUNT(*) 或 AVG(price)，部分数据库不支持，且触发多次聚合计算。
窗口函数里 ORDER BY 的位置极易混淆
ORDER BY 出现在 OVER 子句中（如 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC)）只影响窗口内计算逻辑，不影响最终结果行序。想让整个结果集按用户平均消费额降序排，必须：
- 先用窗口函数算出权重列：
AVG(amount) OVER (PARTITION BY user_id) AS user_avg - 再在外层
ORDER BY user_avg DESC
把 ORDER BY 写在窗口定义里，不代表最终结果就按那个顺序输出——这是最常被忽略的执行顺序陷阱。
