SQL视图定义中直接写ORDER BY会报错，因ANSI SQL标准规定视图是逻辑关系而非游标操作；仅当配合TOP、OFFSET/FETCH或LIMIT用于行数限制时才被允许，且不保证查询结果有序；可靠排序必须在外部查询中显式指定。
SQL视图定义中直接写 ORDER BY 会报错
绝大多数数据库（PostgreSQL、Oracle、MySQL 8.0+、SQL Server 默认模式）在执行 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：语法检查直接失败，不保存视图定义
这不是数据库“不支持”，而是 ANSI SQL 标准（SQL:2003 起）的硬性规定：视图是逻辑关系（set），而 ORDER BY 是游标操作（cursor operation），语义层面不兼容。
只有配合 TOP、OFFSET 或 FETCH 时，ORDER BY 才被允许
SQL Server 和部分新版 PostgreSQL/MySQL 允许在视图定义中写 ORDER BY，但前提是它服务于行数限制逻辑——即必须和以下之一共存：
-
SELECT TOP N ... ORDER BY col（SQL Server） -
SELECT ... ORDER BY col OFFSET 0 ROWS FETCH FIRST 10 ROWS ONLY（标准 SQL） -
SELECT ... ORDER BY col LIMIT 10（PostgreSQL/MySQL，但 MySQL 5.7 及更早版本不严格校验）
注意：ORDER BY 在这里**仅用于确定哪几行被取出来**，不是为了“让视图返回有序结果”。一旦外部查询再 SELECT * FROM my_view，顺序依然不保证。
TOP 100 PERCENT 是个危险的伪解法
SQL Server 中常见写法：SELECT TOP 100 PERCENT * FROM t ORDER BY id，看似绕过限制，实际隐患很大：
- 优化器可能完全忽略该
ORDER BY，尤其在视图被JOIN、嵌套或加WHERE后 - 即使某次执行看起来有序，也无法在任何场景下稳定复现
- SQL Server 官方文档明确警告：这不能作为排序保障手段
它本质是历史兼容性补丁，不是设计意图，生产环境应避免依赖。
真正可靠的做法：排序永远放在外部查询
视图只负责定义“取哪些字段、从哪几张表、用什么条件关联”，排序属于使用阶段的事。正确写法就一条原则：
- 定义视图时：彻底去掉
ORDER BY，哪怕你心里想按created_at DESC - 查询视图时：显式写
SELECT * FROM my_view ORDER BY created_at DESC
ORM 框架里也不要试图全局拦截视图查询自动加 ORDER BY——它会破坏 COUNT(*)、聚合、分页元数据等所有非展示类用途。顺序强依赖的业务逻辑，更适合下沉到应用层或封装成带参数的存储过程。
