因为sql标准规定子查询返回无序集合，order by在中间层无语义意义，优化器会直接忽略或报错；仅当配合limit/top/fetch时才被允许且必要，用于确定截取行而非保证输出顺序。
因为子查询返回的是无序集合，ORDER BY在中间层没有语义意义——它既不改变数据内容，也不影响外层的关联、过滤或分组逻辑，优化器直接删掉它是最合理的执行策略。
子查询里的 ORDER BY 为什么不是“写错了”，而是“根本不该存在”
SQL 标准把表（包括派生表、CTE、视图）定义为数学意义上的集合，而集合本身不带顺序。当你写 FROM (SELECT * FROM t ORDER BY x)，数据库解析时只关心“这个子查询能提供哪些列和行”，不承诺任何物理或逻辑顺序。优化器看到 ORDER BY 后面没跟 LIMIT、OFFSET 或 TOP，就知道它对最终结果无影响，顺手就优化掉了。
- 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 table, subqueries - MySQL 5.7 静默忽略；8.0+ 默认也报错，除非显式加
LIMIT
ORDER BY 在子查询里“起作用”的唯一条件
它必须和行数限制绑定，目的不是排序输出，而是决定“取哪几行”。此时 ORDER BY 是语义必需的，不是装饰。
-
SELECT * FROM (SELECT id FROM t ORDER BY created_at DESC LIMIT 1) s：ORDER BY决定哪条是最新记录 -
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：标准 SQL 中FETCH必须基于明确顺序
注意：这些都不是让你信任子查询输出顺序，而是告诉数据库“按什么规则截断”。一旦去掉 LIMIT 或 TOP，ORDER BY 就又失效了。
GROUP BY + 子查询 + ORDER BY 是最典型的翻车组合
想每组取最新一条，却在子查询里写 ORDER BY updated_at DESC，然后外层 GROUP BY —— 这完全无效。因为 GROUP BY 执行在 ORDER BY 之前，分组时数据库从每组随机挑一行（通常是物理存储顺序的第一行），等排完序只剩每组一条，再排也没意义。
- 错误写法：
SELECT p.*, pp.* FROM product p LEFT JOIN (SELECT * FROM log ORDER BY created_at DESC) pp ON p.id = pp.product_id GROUP BY p.id - 正确做法：用窗口函数绑定排序与取值，如
ROW_NUMBER() OVER (PARTITION BY product_id ORDER BY created_at DESC)，或把LIMIT 1塞进关联子查询中
真正决定最终结果顺序的，只有最外层的 ORDER BY。哪怕你在子查询里靠 LIMIT + ORDER BY 拿到了“看起来有序”的中间结果，只要外层再 JOIN 或 GROUP BY，顺序就可能漂移——这不是 bug，是关系模型的设计必然。
