sql标准禁止子查询中孤立使用order by，因其违背关系模型中集合无序性；order by仅在最终输出生效，唯一例外是与limit/fetch等截断子句绑定以确定取行。
SQL Standard 明确禁止子查询中使用孤立的 ORDER BY，不是数据库“没做出来”，而是标准从数学基础就否定了它的语义合法性。
子查询返回的是集合，不是游标
SQL 把表和子查询结果都定义为数学意义上的「集合」——元素无序、不重复、不可索引。而 ORDER BY 是游标（cursor）操作，作用对象是「有序的结果流」，二者逻辑类型冲突。标准（ANSI SQL-92 起）直接规定：子查询只能输出集合，不能带顺序属性。
- 你写
SELECT * FROM (SELECT id FROM t ORDER BY created_at) s，数据库解析时会把括号内视为一个派生表（derived table），它必须满足「关系模型」要求：行无序、列有序 - 优化器看到这个
ORDER BY没绑定任何截断逻辑（如LIMIT），就知道它对上层 JOIN/GROUP BY/IN 等操作毫无影响，直接删掉以节省排序开销 - PostgreSQL 和 SQL Server 的报错信息非常直白：
ERROR: ORDER BY in subquery is not allowed unless it is accompanied by LIMIT or OFFSET，这不是 bug，是标准强制拦截
ORDER BY 只在逻辑查询处理的最后一步生效
SQL 标准定义了严格的逻辑执行顺序：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY。其中 ORDER BY 是第 10 步，仅作用于最终输出结果集。子查询属于 FROM 子句的一部分（第 1 步），此时连行数都没确定，更谈不上“排序”。
- 即使你看到子查询结果“看起来有序”，那只是存储引擎按物理页顺序扫描的偶然现象，不是契约保证
- MySQL 5.7 静默忽略，是因为它没严格遵循标准；MySQL 8.0+ 默认报错，正是向标准靠拢
- 试图用
TOP 100 PERCENT（SQL Server）或OFFSET 0 ROWS（无FETCH）绕过限制，本质是欺骗优化器，执行计划一变就失效
唯一被允许的例外：ORDER BY 必须服务于行截断
标准只给一种场景开了后门：当 ORDER BY 和 LIMIT / TOP / FETCH FIRST 绑定时，它才被允许且必需——但目的不是“让结果有序”，而是“决定取哪几行”。
-
SELECT * FROM (SELECT id FROM t ORDER BY created_at DESC LIMIT 1) s：ORDER BY是为LIMIT服务的，告诉数据库“最新那条是谁” -
SELECT * FROM t ORDER BY id OFFSET 0 ROWS FETCH FIRST 10 ROWS ONLY：ORDER BY是FETCH的前提，否则“前 10 行”无法定义 - 注意：这些语句里
ORDER BY的作用域仅限于当前子句，外层再JOIN或GROUP BY，顺序就不再受控
最容易被忽略的一点：标准禁止的是「孤立的 ORDER BY」，不是禁止排序本身。真正该放 ORDER BY 的地方永远只有一个——最外层查询。其他所有中间层的排序企图，要么被删，要么被报错，要么看似有效实则不可靠。
