SQL Server 2008+ 会主动优化掉 TOP 100 PERCENT + ORDER BY，因其被识别为全表返回而移除 Sort 算子；标准 SQL 规定视图不保证顺序，稳定排序必须在最外层 SELECT 中显式指定 ORDER BY。
SQL Server 2008+ 会直接优化掉 TOP 100 PERCENT + ORDER BY
这不是 bug，是查询优化器的主动行为。从 SQL Server 2008 开始，优化器识别到 TOP 100 PERCENT 等价于“全表返回”，于是直接移除 ORDER BY 对应的 Sort 算子——执行计划里根本看不到排序操作，哪怕你写了 ORDER BY created_at DESC。
常见错误现象：
- 视图定义能通过，
SELECT * FROM my_view偶尔看起来有序，但换一次查询、加个WHERE或 JOIN 就乱序 - 升级到 SQL Server 2016+ 或迁移到 Azure SQL 后，原来“好使”的视图突然不按预期排序
- 微软已在文档中标记
TOP 100 PERCENT为“不推荐”，未来版本可能彻底移除
TOP 100 PERCENT 只解决语法报错，不解决语义保序
TOP 100 PERCENT 的唯一作用是绕过“视图中不能写 ORDER BY”的语法校验，它不是排序指令，而是告诉解析器：“我打算取全部行，所以允许我写 ORDER BY”。但标准 SQL 规定：视图是虚拟表，表本身无序；排序只在最终结果输出时生效。
使用场景误判：
- 想用视图封装“最新 10 条记录”？该用
ORDER BY x OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY - 想让前端分页控件依赖首行是最新数据？必须在外层查视图时加
ORDER BY，否则顺序不可靠 - 试图靠它实现稳定分页或导出顺序？并行扫描、索引选择变化、统计信息更新都会导致两次查询返回不同顺序
替代方案：用窗口函数把排序逻辑转为列值
如果业务强依赖固定顺序（比如日志视图总要按时间倒序），与其在视图里硬塞 ORDER BY，不如把排序决策固化为可排序的列值：
CREATE VIEW v_sorted_events AS SELECT *, ROW_NUMBER() OVER (ORDER BY event_time DESC) AS _rn FROM events;
调用时写：SELECT * FROM v_sorted_events ORDER BY _rn。这样既利用了索引（event_time 上有索引时 ROW_NUMBER() 效率高），又把排序控制权交还给外层查询。
注意点：
-
ROW_NUMBER()比RANK()更贴近原始ORDER BY语义（重复值不会跳号） - 这个方案不改变视图“无序”的本质，但提供了可预测、可复用的排序锚点
- 仍需在外层显式
ORDER BY _rn，否则结果顺序依然不可靠
真正有效的排序永远只发生在最外层 SELECT
无论你用视图、CTE、内联函数还是派生表，只要没在最终 SELECT 语句里写 ORDER BY，数据库就没有任何义务保证返回顺序。这是关系模型的基本约束，不是数据库厂商的限制。
容易被忽略的细节：
- 即使你在视图里成功用了
OFFSET 0 ROWS FETCH NEXT 100 ROWS ONLY，它也只是截取前 N 行，不等于“全局有序” - PostgreSQL 和 MySQL 8.0+ 允许视图语法含
ORDER BY，但执行时照样忽略——不是它们不支持，而是标准不允许 - 所有试图在中间层固化顺序的做法，都在和 SQL 的集合语义对抗；而集合，天生没有顺序
