SQL标准规定子查询返回无序集合，因表被定义为数学集合，天然无序；ORDER BY仅作用于最终结果集，子查询中无效，除非配合LIMIT/TOP/FETCH用于截取行。
SQL标准明确定义子查询返回无序集合
子查询（包括派生表、CTE、视图定义）在 SQL 标准中被建模为数学意义上的「集合」，而集合天然不带顺序。ORDER BY 是作用于最终结果集的逻辑操作，属于查询处理的第 10 步（输出阶段），但子查询位于 FROM 子句（第 1 步），此时连行是否被保留都未确定，排序没有语义基础。数据库不是“不支持”，而是按标准主动拒绝——PostgreSQL 报 ERROR: ORDER BY in subquery is not allowed unless it is accompanied by LIMIT or OFFSET，SQL Server 报 Msg 1033，都是合规行为，不是 bug。
MySQL 5.7 和 8.0+ 的处理差异很关键
MySQL 5.7 对子查询里的 ORDER BY 静默忽略，看起来没报错，但排序实际无效；MySQL 8.0+ 默认严格遵循标准，直接语法报错，除非你显式加上 LIMIT。这意味着：
- 写
SELECT * FROM (SELECT id FROM t ORDER BY created_at DESC) s在 5.7 不报错但结果不可靠，在 8.0+ 直接失败 -
LIMIT值必须覆盖你要取的全部数据，比如想全量排序后分组取最新，不能写LIMIT 100，得写足够大的数（如LIMIT 9999999） - 即使加了
LIMIT，也只是让数据库知道“按什么规则截取”，不是承诺子查询输出有序——外层仍需自己ORDER BY
TOP 100 PERCENT 是 SQL Server 的危险兼容补丁
有人用 SELECT TOP 100 PERCENT * FROM t ORDER BY id 塞进视图或子查询来绕过报错，但这只是历史遗留的优化器欺骗手段：
- SQL Server 文档已明确标记为“不推荐”，Azure SQL 中可能失效
- 一旦该子查询被 JOIN 或加 WHERE，优化器大概率抹掉排序步骤
- 它生成的是带排序的执行计划，不是稳定的结果顺序，
OPTION (RECOMPILE)也只影响计划，不保证输出
真正可靠的做法只有两种
你需要区分清楚：是要「取某几行」，还是「让最终结果有序」？
- 如果目标是每组取最新一条，用窗口函数：
ROW_NUMBER() OVER (PARTITION BY type ORDER BY updated_at DESC)，然后外层WHERE rn = 1 - 如果目标是最终展示有序，排序必须放在最外层查询：
SELECT * FROM my_view ORDER BY created_at DESC，且字段必须出现在视图 SELECT 列表中（尤其 PostgreSQL/SQL Server） - 别依赖子查询排序“顺带”影响外层，哪怕看起来偶尔有序，那也只是物理扫描顺序的偶然，统计信息更新或索引重建后就变了
