子查询中ORDER BY被忽略是SQL标准强制行为，非bug；因子查询返回无序集合，ORDER BY仅在最终结果集生效，仅当配合LIMIT/TOP/FETCH时才被允许且用于确定截取行。
子查询里ORDER BY被忽略是标准行为，不是bug
SQL 标准（ANSI SQL-92 起）明确定义：子查询、派生表、CTE、视图返回的都是「无序集合」。ORDER BY 是作用于最终结果集的游标操作，中间层没有语义意义。数据库优化器发现它对上层逻辑（如 JOIN、GROUP BY、WHERE IN）无实际影响，就会直接删掉——省排序开销，也避免误导开发者以为“顺序可控”。
- 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或OFFSET）
哪些场景下ORDER BY在子查询里“看起来有效”
只有当 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：标准分页语法，ORDER BY是FETCH的前提
注意：这些都不是让你信任子查询输出顺序。一旦外层加 JOIN 或 GROUP BY，优化器很可能重排——你看到的顺序只是物理扫描的偶然结果。
为什么加了LIMIT还不生效？常见失效原因
即使写了 ORDER BY ... LIMIT，也可能因底层机制未触发 Top-N 优化，导致全表扫描 + filesort：
- 排序字段没走索引：比如
ORDER BY score DESC，但score列无索引，或索引不是最左前缀（如联合索引是(status, score)，但查询没带WHERE status = ?） - 类型不一致导致隐式转换：子查询中
id是INT，外层WHERE id IN (subquery)却拿BIGINT比较，MySQL 可能放弃排序逻辑 - 外层过滤破坏语义：比如子查询取“最新10条”，但外层
JOIN后只保留其中3条匹配行，结果既非最新、也不满10条 -
LIMIT值太小且未覆盖目标数据量：如用LIMIT 100包裹全量数据用于GROUP BY，实际需取每组 top1，但 100 不够覆盖所有分组
真正该写ORDER BY的地方只有一个
最终结果顺序只能由最外层的 ORDER BY 决定，且必须配合索引才能避免性能灾难：
- 不要把
ORDER BY塞进视图定义、CTE 或派生表里试图“固化顺序” - 不要依赖
TOP 100 PERCENT（SQL Server）这类兼容性补丁——它不固化顺序，只骗过语法检查，执行计划一变就失效 - 分页需求优先用标准
OFFSET ... FETCH，但调用方仍需在最外层显式写ORDER BY才能得到确定顺序 - 想每组取最新一条，用
ROW_NUMBER() OVER (PARTITION BY x ORDER BY y DESC)，把排序和编号锁在同一层
最容易被忽略的一点：哪怕你靠 LIMIT 或 FETCH 让子查询里的 ORDER BY 语法通过并执行了，只要最终查询没在最外层写 ORDER BY，每次返回的行序都可能不同——并行扫描、索引统计更新、存储引擎版本变化都会让它漂移。
