子查询中ORDER BY被拒绝是因SQL标准规定其返回无序集合，仅当配合LIMIT/TOP/FETCH时才有效，用于确定截取行而非保证顺序；否则优化器直接丢弃，PostgreSQL和SQL Server报错、MySQL 5.7静默忽略、8.0+需加LIMIT才允许。
子查询里写 ORDER BY 直接报错或静默失效，不是数据库 bug，而是 SQL 标准强制要求：子查询返回的是无序集合，ORDER BY 只对最终结果集有意义。
子查询中 ORDER BY 为什么被拒绝？
SQL 把表定义为数学意义上的集合，不带顺序。子查询（比如 WHERE id IN (SELECT ...) 或 FROM (SELECT ...)）只是提供中间数据，数据库优化器会直接丢掉无用的排序逻辑——既不影响过滤、聚合，也不影响关联结果。所以 PostgreSQL 和 SQL Server 直接语法报错；MySQL 8.0+ 默认也报错，5.7 则静默忽略。
-
ERROR: ORDER BY in subquery is not allowed unless it is accompanied by LIMIT or OFFSET（PostgreSQL） -
The ORDER BY clause is invalid in views, inline functions, derived tables, subqueries...（SQL Server） - MySQL 5.7 不报错但排序无效；8.0+ 需显式加
LIMIT才允许语法通过
什么时候 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必须依赖内层ORDER BY才能复现语义 -
SELECT * FROM t ORDER BY id OFFSET 0 ROWS FETCH FIRST 10 ROWS ONLY——FETCH同理，ORDER BY是前提
注意：这些都不是让你“信任子查询输出顺序”，而是让数据库知道“按什么规则截取”。
GROUP BY + ORDER BY + 子查询最容易翻车的地方
典型错误：想每组取最新一条，却把 ORDER BY 放在子查询或外层 SELECT 里，结果拿到的是随机行。
- 执行顺序是
GROUP BY先于ORDER BY，分组时数据库从每组任选一行（通常是存储顺序第一行） - 等排完序只剩每组一条，再排也没意义
- 正确做法是把排序和取值绑在同一层：用
ROW_NUMBER() OVER (ORDER BY ...)或LIMIT+ 子查询嵌套
例如：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY group_id ORDER BY updated_at DESC) rn FROM t) WHERE rn = 1
视图、CTE、派生表里写 ORDER BY 安全吗？
不安全。即使语法允许（如某些数据库支持 FROM (SELECT ... ORDER BY x LIMIT n)），外部查询一旦加 JOIN 或 GROUP BY，优化器很可能重排——你看到的顺序只是巧合，不是契约。
- SQL Server 的
TOP 100 PERCENT ORDER BY是危险补丁，仅骗过语法检查，执行计划一变就失效 - 视图定义中写
ORDER BY几乎全部被禁止（PostgreSQL/Oracle/SQL Server 默认模式） - 真正该排序的地方只有一个：查视图的时候，即
SELECT * FROM my_view ORDER BY created_at DESC
最易被忽略的一点：子查询里的 ORDER BY 不是“没写对”，而是“根本不该存在”——除非它明确服务于 LIMIT、TOP 或 FETCH。其他所有场景，删掉它，把排序移到最外层，才是干净解法。
