子查询中ORDER BY通常无效，因SQL标准规定其仅作用于最终结果；仅当配合LIMIT/TOP/FETCH等截断子句或用于窗口函数时才生效，安全做法是将ORDER BY移至外层查询。
在 SQL 子查询中，ORDER BY 通常不生效，除非子查询同时满足两个关键条件：带有 LIMIT（或 TOP、FETCH FIRST 等等效语法），且该子查询用于特定上下文（如派生表、窗口函数或某些数据库的 LIMIT 子句中）。标准 SQL 规范明确指出：子查询本身不保证结果顺序，ORDER BY 单独出现在子查询中会被忽略。
为什么子查询里的 ORDER BY 大多被忽略？
SQL 标准将“逻辑查询处理”分为多个阶段，ORDER BY 属于最后一步，仅作用于最终结果集。子查询（尤其是非相关子查询）被视为一个中间结果集，其内部排序对上层查询无意义——因为上层可能做 JOIN、IN、聚合或再次排序，数据库优化器会直接丢弃无用的排序操作以提升性能。
例如：
-- 这个 ORDER BY 不起作用，多数数据库会报错或静默忽略SELECT * FROM (SELECT id, name FROM users ORDER BY created_at DESC) AS t;
哪些情况 ORDER BY 在子查询中才有效？
-
带 LIMIT 的派生表（最常见有效场景）：MySQL、PostgreSQL、SQL Server（含 OFFSET/FETCH）等支持在子查询中用
ORDER BY ... LIMIT来定义“取最新/最前 N 条”。此时ORDER BY是为LIMIT服务的，必须存在。 -
作为窗口函数的源数据（需配合 OVER）：虽然子查询本身不排序，但若在
OVER (ORDER BY ...)中引用字段，实际排序由窗口定义驱动，而非子查询的ORDER BY。 -
某些数据库的特殊语法（如 SQL Server 的 TOP + ORDER BY）：
SELECT TOP 5 * FROM (SELECT * FROM logs ORDER BY time DESC) t中，内层ORDER BY是合法且必需的，否则TOP行为不可控。
如何安全地控制子查询结果顺序？
- 如果目标是取有序的前 N 条记录，直接在子查询中写
ORDER BY ... LIMIT N（MySQL/PG）或ORDER BY ... OFFSET 0 ROWS FETCH FIRST N ROWS ONLY（标准 SQL）。 - 如果只是想让外层结果有序，把
ORDER BY移到最外层查询，这是最可靠、可移植的做法。 - 避免在
IN、= ANY、标量子查询中写ORDER BY—— 不仅无效，还可能引发语法错误（如 MySQL 8.0+ 严格模式下报错）。
不同数据库的实际表现差异
MySQL 5.7 允许子查询带 ORDER BY（即使无 LIMIT），但不保证效果；MySQL 8.0+ 默认报错，除非加 LIMIT。PostgreSQL 更严格，无 LIMIT 的子查询中 ORDER BY 直接报错。SQL Server 要求 TOP 或 OFFSET/FETCH 配合 ORDER BY 才允许出现。
所以，跨数据库兼容写法只有一条：不要依赖子查询中的 ORDER BY，需要顺序就放外层，需要截断就配 LIMIT 或 FETCH。
