因为SQL标准规定子查询返回无序集合，ORDER BY在中间层无语义意义，数据库优化器会直接忽略或报错；仅当配合LIMIT/TOP/FETCH时才被允许且必要，用于确定截取行而非保证输出顺序。
子查询里写 ORDER BY 为什么数据库直接忽略或报错？
因为 SQL 标准规定：子查询（包括视图、CTE、派生表）返回的是「无序集合」，ORDER BY 在中间层没有语义意义。数据库优化器会直接删掉它——不是 bug，是设计如此。
SQL Server 报错 1033，PostgreSQL 拒绝语法（除非配 LIMIT 或 OFFSET），MySQL 5.7 会静默优化掉，8.0+ 则强制要求 LIMIT 才允许写。本质都是在阻止你误以为“子查询排好序了，外层就能按这个顺序拿数据”。
-
ORDER BY只在最终结果集生成阶段（逻辑处理第 10 步）才生效 - 子查询属于
FROM子句的一部分（第 1 步），此时连行数都未确定，排序无从谈起 - 即使你看到“结果看起来有序”，那只是存储引擎扫描物理页的偶然顺序，不可依赖
哪些场景下 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：FETCH同理，ORDER BY是前提
注意：这些都不是让你信任子查询输出顺序，而是告诉数据库“按什么规则截取”。一旦去掉 LIMIT 或 TOP，排序就又失效了。
MySQL 5.7 中 ORDER BY 在子查询里静默失效的典型表现
比如想查每种图书类型浏览量最高的那本：
SELECT type, book_name FROM ( SELECT * FROM book ORDER BY visits_num DESC ) t1 GROUP BY type
在 MySQL 5.7 上，ORDER BY 被优化器直接跳过，GROUP BY 随机取每组第一行，结果不可控。解决方法只有显式加 LIMIT 强制保留排序逻辑：
SELECT type, book_name FROM ( SELECT * FROM book ORDER BY visits_num DESC LIMIT 9999999 ) t1 GROUP BY type
-
LIMIT值必须足够大，覆盖所有可能行数（不能写LIMIT 100然后指望取全量） - MySQL 8.0+ 允许不加
LIMIT但语法通过，行为仍不保证；5.7 是真·静默丢弃 - 更安全的做法是改用窗口函数：
ROW_NUMBER() OVER (PARTITION BY type ORDER BY visits_num DESC)
SQL Server 里用 TOP 100 PERCENT 是权宜之计
遇到报错 “ORDER BY 在子查询中无效”，有人会写：
SELECT * FROM ( SELECT TOP 100 PERCENT * FROM tab ORDER BY userID DESC ) a ORDER BY date DESC
这能绕过语法检查，但有严重隐患：
-
TOP 100 PERCENT不提供任何语义保证，SQL Server 2012+ 已明确将其优化为无操作 - 执行计划里看不到排序节点，实际仍可能乱序
- 仅适用于兼容性兜底，新项目应避免，改用
OFFSET 0 ROWS FETCH NEXT N ROWS ONLY或外层排序
真正需要子查询有序，就得把排序逻辑移到最外层 SELECT，或者用 CTE + 窗口函数替代。
