视图中写order by或窗口函数（如row_number()）不会使最终结果有序，因视图仅封装select逻辑而不固化顺序或提前计算；窗口函数在查询视图时才执行，其结果为一列而非全局排序。
视图里写 ORDER BY 或窗口函数（如 ROW_NUMBER()）本身不会让最终查询结果有序，这不是 bug，是 SQL 标准和数据库引擎执行模型决定的——视图只是封装了 SELECT 逻辑，不固化顺序，也不提前计算窗口值。
视图定义中窗口函数能用，但排序效果不保留
你可以在视图定义里写 ROW_NUMBER() OVER (ORDER BY created_at DESC)，语法上多数数据库（PostgreSQL、SQL Server、MySQL 8.0+）都允许。但它只在“查询该视图时”才真正计算，且计算结果是作为一列输出，不是对整个结果集施加物理排序。
- 视图本质是预定义的查询语句，不是缓存结果；每次查它，都重新执行内部逻辑
-
ORDER BY在视图定义中会被忽略（PostgreSQL）或要求搭配TOP/LIMIT才通过（SQL Server），但即使通过，也不保证外层查询顺序 - 窗口函数同理：它依赖于当前查询的输入行集和
OVER子句定义的窗口范围，而这些只有在最外层查询执行时才确定
WHERE 中不能直接引用窗口函数别名
常见错误是想在查视图时加 WHERE rn ，却发现报错：<code>window functions are not allowed in WHERE（PostgreSQL）或类似提示。原因很直接：SQL 执行顺序中，WHERE 在窗口函数计算之前就完成了。
- 执行阶段顺序是：
FROM→WHERE→GROUP BY→HAVING→SELECT（含窗口函数）→ORDER BY - 所以你在视图里定义的
rn别名，在外层WHERE看来根本不存在 - 正确做法只能是再套一层：把查视图的语句当子查询或 CTE，外层再
WHERE筛选别名
MySQL 5.7 或更老版本连窗口函数语法都不支持
如果你用的是 MySQL 5.7、MariaDB 10.2 以前，或者 SQL Server 2005/2008 R2，那不是“无法排序”，而是压根解析不了 OVER 语法，会直接报错：ERROR 1064 或 Incorrect syntax near 'OVER'。
- MySQL 8.0+ 才原生支持窗口函数；SQL Server 2005+ 支持部分，但 2008 R2 对
ROWS BETWEEN等高级用法支持弱 - 旧版替代方案只能靠自连接、用户变量或临时表模拟，但要注意：用户变量在并行查询或优化器重排后行为不可靠
- 如果必须兼容老版本，建议把窗口逻辑下沉到应用层做排序/分页，或改用物化中间表 + 索引
ORDER BY 在 OVER 里到底控制什么？
OVER (ORDER BY x) 不是对最终结果排序，而是定义窗口内行的处理顺序——它直接影响编号、滑动计算边界、累计值走向。这点容易被误读。
- 比如
AVG(amount) OVER (ORDER BY ts ROWS BETWEEN 2 PRECEDING AND CURRENT ROW)，ORDER BY ts决定了哪三行参与平均，不是让最终结果按ts排 - 如果
ts有重复值（如秒级时间戳），不同数据库对相同ts行的相对顺序可能不一致，导致ROW_NUMBER()每次结果不同 - 安全做法是在
ORDER BY后追加唯一列兜底，例如ORDER BY created_at, id
真正需要固定顺序输出时，ORDER BY 必须出现在最外层查询末尾；真正需要基于窗口逻辑过滤时，必须用子查询或 CTE 套一层；而是否能用窗口函数本身，先看数据库版本——这些都不是设计缺陷，而是 SQL 执行模型的必然约束。漏掉任意一环，结果就不可控。
