CREATE VIEW 中 ORDER BY 被标准禁止且被主流数据库主动拒绝，因视图是无序关系而 ORDER BY 是游标操作；唯一可靠排序是在最外层查询显式指定 ORDER BY。
视图定义里写 ORDER BY 不是“失效”，而是被数据库主动拒绝或静默丢弃——这不是实现不到位，是 SQL 标准（ANSI SQL-92 起）明确禁止的行为。
为什么 CREATE VIEW 里直接写 ORDER BY 必然报错
几乎所有主流数据库在解析 CREATE VIEW 语句时，只要子查询中出现孤立的 ORDER BY，就会中断执行：
-
SQL Server报Msg 1033, Level 15, State 1：“The ORDER BY clause is invalid in views” -
PostgreSQL报ERROR: ORDER BY in a view's SELECT list is not allowed -
MySQL 8.0+在语法检查阶段就失败，视图根本存不进去
这不是版本低、配置错或权限问题，而是引擎层对标准的强制执行：视图是逻辑关系（set），而 ORDER BY 是游标操作（cursor operation），二者语义冲突。
TOP 100 PERCENT 和 OFFSET 0 ROWS 都不是真解法
有人用 SELECT TOP 100 PERCENT * FROM t ORDER BY id 或 ORDER BY id OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY 塞进视图，看似绕过语法限制，但实际作用非常有限：
-
TOP 100 PERCENT是 SQL Server 的历史兼容补丁，官方文档已标记为“不推荐”，Azure SQL 中行为更不可靠 - 优化器在视图被
JOIN、加WHERE或嵌套调用时，大概率抹掉该排序步骤 -
OFFSET 0 ROWS FETCH NEXT N ROWS ONLY允许进视图，但它只定义“取哪几行”，不承诺结果对外有序；SELECT * FROM my_view仍可能每次返回不同顺序
真正起作用的 ORDER BY 只能在最外层查询中显式写出
排序控制权必须交给最终使用者，这是唯一符合标准且稳定生效的方式：
- ✅ 正确：
SELECT * FROM user_orders_view ORDER BY order_time DESC LIMIT 10 - ❌ 错误：
SELECT * FROM (SELECT * FROM user_orders_view ORDER BY order_time DESC) t LIMIT 10—— 子查询里的ORDER BY若无LIMIT或FETCH，会被优化器忽略 - 注意：如果视图含
DISTINCT或聚合，外层ORDER BY字段必须出现在视图的SELECT列表中，否则PostgreSQL/SQL Server会报错
最容易被忽略的一点：没有最外层 ORDER BY，就没有顺序保证
哪怕你用了 OFFSET-FETCH、建了索引、甚至把视图改成物化视图，只要调用方没在最外层显式写 ORDER BY，数据库就没有任何义务返回确定顺序。这不是性能问题，也不是 bug，是关系模型的基本前提：表和视图都是无序集合。
