子查询中ORDER BY通常无效，因SQL标准规定其仅作用于最终结果；仅当配合LIMIT/TOP/FETCH等截断子句时才生效，用于确定截取行而非保证输出顺序。
子查询里的 ORDER BY 本来就不该生效——这不是 bug，是 SQL 标准强制要求的结果。
为什么子查询中写 ORDER BY 会被忽略或报错
SQL 把“表”（包括子查询产生的派生表）定义为数学意义上的集合，而集合本身无序。数据库优化器看到子查询里有 ORDER BY 但没配套截断逻辑（如 LIMIT、TOP、FETCH），就直接丢掉排序步骤，省掉无效计算开销。
- PostgreSQL：直接语法报错
ERROR: ORDER BY in subquery is not allowed unless it is accompanied by LIMIT or OFFSET - SQL Server：报错
The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries - MySQL 5.7：静默忽略，排序不执行；8.0+ 默认也拒绝，除非加
LIMIT
ORDER BY 在子查询里什么情况下才真起作用
只有一种场景它被真正执行：配合行数限制，用来决定“取哪几行”，而不是为了对外输出顺序。
-
SELECT * FROM (SELECT id FROM t ORDER BY created_at DESC LIMIT 1) s——ORDER BY是为LIMIT服务的 -
SELECT TOP 5 name FROM users ORDER BY score DESC——TOP语义依赖内层排序 -
SELECT * FROM t ORDER BY id OFFSET 0 ROWS FETCH FIRST 10 ROWS ONLY——FETCH必须基于明确顺序
注意：这些都不是让你“信任子查询输出顺序”，而是告诉数据库“按什么规则截取”。一旦去掉 LIMIT 或等价结构，ORDER BY 就又失效了。
GROUP BY + 子查询 + ORDER BY 组合最容易翻车
典型错误写法：SELECT * FROM (SELECT * FROM orders ORDER BY created_at DESC) t GROUP BY customer_id。你以为每组拿到的是最新一条，实际返回的是每组任意一行（通常是物理存储第一条）。
- 原因：MySQL 5.7+ 启用
derived_merge优化，直接把子查询的ORDER BY当作无意义操作丢弃 - 临时 workaround：加一个极大
LIMIT，比如LIMIT 999999999，干扰优化器判断 - 真正可靠方案：改用窗口函数，例如
ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY created_at DESC)，再过滤rn = 1
视图、CTE、UNION 中的 ORDER BY 同样不可信
视图定义里写 ORDER BY 不影响输出顺序；CTE 里写也一样；UNION 的每个分支单独加 ORDER BY 会报错，必须用括号包住并配 LIMIT 才合法。
- UNION 正确写法：
(SELECT * FROM a ORDER BY x DESC LIMIT 9999) UNION (SELECT * FROM b) - 视图排序唯一有效位置：最外层查询，即
SELECT * FROM my_view ORDER BY updated_at DESC - CTE 中
ORDER BY仅在配合LIMIT或作为递归终止条件时才有意义
真正容易被忽略的是：哪怕你用 LIMIT 强制保留了子查询排序，只要后续有 JOIN 或 GROUP BY，数据库仍可能重排结果——最终顺序只由最外层的 ORDER BY 决定，且该字段必须出现在 SELECT 列表中（尤其在 PostgreSQL/SQL Server 下）。
