SQL Server视图定义中ORDER BY的替代方案，您倾向于哪种？

我倾向于在查询或应用程序层面使用ORDER BY，而不是在视图定义中直接包含它。

为什么视图定义中要避免ORDER BY

在SQL Server中，视图本质上是一个保存的查询，它像一个虚拟表。虽然技术上可以在视图定义里写ORDER BY，但这通常不是好做法。因为视图本身并不存储数据，它只是每次被查询时重新执行。如果在视图里加了ORDER BY，那么每次从这个视图中选择数据，即使你不需要排序，系统也会强制进行排序操作，这会降低性能。特别是当数据量很大时，这种不必要的排序会成为瓶颈。更关键的是，这种排序的目的常常是为了展示数据，而展示逻辑应该由最终查询或应用程序来控制，这样更灵活。

实用的替代方案

最好的办法是把排序留给使用视图的查询。比如，你创建了一个名为“CustomerView”的视图，里面列出了客户信息但没有排序。当你在程序或报告中需要这些数据时，再在查询语句的最后加上ORDER BY子句，比如“SELECT * FROM CustomerView ORDER BY LastName”。这样，你可以根据实际情况决定按什么字段排序，甚至可以根据不同情况使用不同的排序方式。另一个方案是在应用程序代码里处理排序。很多现代的开发框架和报表工具都内置了数据排序功能。你可以从视图中获取原始数据，然后在内存中进行排序。这种方法对于中小型数据集很有效，因为它把排序负担从数据库服务器转移到了应用服务器或客户端，可以更灵活地响应用户的交互操作，比如点击表头排序。

什么时候可以考虑在视图中排序

虽然通常不建议，但在极少数情况下，如果某个排序顺序是业务逻辑的核心部分，并且几乎所有使用该视图的场景都需要相同的排序，那么可以考虑。但即便如此，也要注意性能影响，并确保有相应的索引支持。更常见的做法是使用TOP或OFFSET-FETCH子句来限制返回的行数，这时ORDER BY是必需的，因为它决定了哪些行被选中。例如，创建一个返回最近10个订单的视图，就需要在视图定义中使用ORDER BY和TOP来确保正确性。

实践建议与总结

我的经验是：保持视图简单，只负责筛选和组合数据，把排序、分页这些展示层的逻辑放到外层。创建视图时，专注于数据本身的关系和过滤条件。如果需要为排序优化，可以在底层表的相关列上创建索引，这会显著提升外层查询排序的速度。养成习惯，在从视图选择数据时显式地加上ORDER BY。这样代码意图更清晰，也便于维护。记住，视图的目的是简化复杂查询和提供一致的数据视角，而不是决定数据的最终呈现顺序。

FAQ

问题1：如果我在视图定义中使用了ORDER BY，会有什么具体坏处？
主要问题是性能。每次查询该视图，即使你只是想快速查看几行数据或进行聚合计算，数据库都会执行完整的排序操作。这会消耗额外的CPU和内存资源，尤其是在数据量大的情况下。此外，它限制了灵活性，因为所有用户都只能得到同一种排序结果，无法根据自身需求调整。

问题2：有没有例外情况，必须在视图里用ORDER BY？
有的。当视图使用TOP、OFFSET或FETCH子句来返回特定范围的行时，必须配合ORDER BY来定义行的顺序。例如，“CREATE VIEW TopSales AS SELECT TOP 10 * FROM Sales ORDER BY Amount DESC”。这里的ORDER BY是为了确定哪10行是“Top”，是逻辑的一部分。

问题3：对于报表这类总是需要固定排序的场景，怎么办？
建议创建一个存储过程来代替视图。存储过程可以包含完整的SELECT语句和ORDER BY子句，并且可以被报表工具直接调用。这样既保证了固定的输出顺序，又避免了将排序逻辑硬编码到视图中所带来的潜在性能问题和理解上的混淆。或者，也可以在报表工具的查询设计器中直接编写包含排序的SQL。

引用来源：基于SQL Server官方文档关于CREATE VIEW的说明以及常见的数据库性能优化最佳实践。