子查询中order by无效是sql标准强制要求，因子查询返回无序集合；仅当配合limit/top/fetch时才被允许且必要，用于确定截取行而非保证输出顺序。
子查询里写 ORDER BY 就是无效操作
SQL 标准把子查询（包括派生表、CTE、视图）定义为「无序集合」，ORDER BY 在中间层没有语义意义——它既不参与过滤，也不影响关联或聚合逻辑。数据库优化器不是“忘了执行”，而是**主动删掉**这个子句，因为保留它纯属浪费 CPU 和内存。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 才允许语法通过。
只有和 LIMIT/TOP/FETCH 绑定时才被真正执行
ORDER BY 在子查询里唯一能起作用的场景，是配合行数限制决定“取哪几行”，而不是为了输出顺序。这时排序是语义必需的，优化器会保留并下推它：
-
SELECT * FROM (SELECT id FROM t ORDER BY created_at DESC LIMIT 1) s：ORDER BY决定哪条是最新记录，LIMIT 1依赖它才能选对 -
SELECT TOP 5 name FROM users ORDER BY score DESC：SQL Server 要求TOP必须有明确排序依据 -
SELECT * FROM t ORDER BY id OFFSET 0 ROWS FETCH FIRST 10 ROWS ONLY：标准 SQL 的分页语法，ORDER BY是FETCH的前提
注意：这些都不是让你相信“子查询返回有序结果”，而是告诉优化器“按这个顺序截取”。一旦去掉 LIMIT 或等价结构，排序就又失效了。
MySQL 5.7 下可能连结果都变空
在 MySQL 5.7 中，如果子查询写了 ORDER BY 却没加 LIMIT，优化器不仅忽略排序，还可能判定整个子查询逻辑冗余，极端情况下直接优化成空结果集。典型表现是：
- 单独执行子查询能查出数据，嵌套进
FROM后返回空 - EXPLAIN 显示
type=ALL且rows为 0，说明优化器跳过了扫描 - 升级到 MySQL 8.0+ 后语法报错，反而更容易暴露问题
这不是 bug，是官方文档明确记载的优化行为（参考 MySQL 5.7 Optimizer Restrictions）。
真正决定最终顺序的只有最外层 ORDER BY
无论嵌套多少层，只有最外层的 ORDER BY 才控制最终结果集顺序。但要注意：
- 外层
ORDER BY字段必须有索引支持，否则触发filesort，性能断崖式下降 - 索引需满足最左前缀原则：比如
WHERE status = 'shipped' ORDER BY created_at DESC，索引应建为(status, created_at) - 多表 JOIN 后再排序，字段来源表必须参与驱动顺序，否则优化器可能放弃索引扫描
嵌套层里的 ORDER BY 除了和 LIMIT 配套用，其他情况全是幻觉——你看到的“有序”，只是存储引擎读物理页的偶然顺序，不可依赖，也不能用于业务逻辑判断。
