SQL标准禁止视图定义中直接使用ORDER BY，因其违背集合无序性；唯一可靠排序方式是在调用视图的外层查询中显式添加ORDER BY。
视图定义里写ORDER BY会报错
SQL标准不允许在视图定义中直接使用 ORDER BY，除非配合 TOP、OFFSET 或 FOR XML 等限定子句（SQL Server特有）。直接写 CREATE VIEW v AS SELECT * FROM t ORDER BY id; 会触发错误：Msg 1033, Level 15, State 1: The ORDER BY clause is invalid in views。
根本原因是：视图代表的是一个**逻辑结果集**，而集合本身无序；ORDER BY 生成的是有序游标，二者语义冲突。数据库引擎拒绝这种定义，不是 bug，而是设计约束。
- MySQL 8.0+ 和 PostgreSQL 完全禁止视图中出现
ORDER BY - SQL Server 允许但仅限于带
TOP (100) PERCENT或OFFSET 0 ROWS的“伪装”写法，但不推荐——它不保证最终查询结果有序 - 即使创建成功，下游
SELECT * FROM v仍可能打乱顺序，因为视图被当作表引用后，外层没ORDER BY就不保证排序
真正生效的排序必须在外层查询加ORDER BY
视图只负责封装查询逻辑，不负责输出顺序。要得到确定排序，必须在调用视图时显式写 ORDER BY：
SELECT * FROM user_summary_view ORDER BY created_at DESC, score DESC;
这是唯一可靠的方式。注意以下几点：
- 不能依赖视图内部的
ORDER BY“惯性”，哪怕它看起来生效了——那是巧合，不是保证 - 如果视图已含
GROUP BY或聚合，外层ORDER BY只能引用视图输出列名（不能用原始表字段名） - 别名在视图中定义后，外层
ORDER BY可直接用，比如视图里写了SELECT name AS full_name，外层就能写ORDER BY full_name
想默认按某列排？用物化方式或应用层控制
如果业务上“总希望按时间倒序看这个视图”，不要试图在视图里硬塞 ORDER BY，而应：
- 在应用代码里每次查视图都补上
ORDER BY created_at DESC（最简单、最可控） - 建索引加速外层排序：在视图底层表的
created_at列上建索引，避免Filesort开销 - 用带排序的内联表值函数（TVF）替代视图（SQL Server）：函数可接受参数并返回有序结果，但调用时仍需显式
ORDER BY才能保证输出顺序 - 避免用
TOP 100 PERCENT ORDER BY做障眼法——SQL Server 2012+ 已明确文档指出：“此语法不保证结果有序”
ORDER BY 在子查询里也一样受限
和视图同理，普通子查询（非派生表或 CTE）里写 ORDER BY 也会报错，除非配合 TOP 或 OFFSET。例如：
SELECT * FROM (SELECT id, name FROM users ORDER BY name) t;
这在大多数数据库中非法。正确写法是把排序移到外层：
SELECT * FROM (SELECT id, name FROM users) t ORDER BY t.name;
CTE 是个例外：CTE 本身不执行，只是命名查询块，所以 CTE 内部可以写 ORDER BY，但仅当它被用于 INSERT ... SELECT 或带 TOP 的上下文才生效；单独 SELECT * FROM cte 仍不保证顺序。
核心就一点：SQL 的排序行为只在**最终结果集生成阶段**由最外层 ORDER BY 控制，中间任何嵌套层级的排序声明，都不构成输出顺序承诺。
