【发布时间】：2010-09-24 12:10:41
【问题描述】：
我在工作中与一位同事讨论过，是关于 SQL 查询和排序的。他认为您应该让服务器在将行返回给客户端之前进行任何排序。另一方面，我认为服务器可能已经够忙了，让客户端在获取行后处理排序必须更好的性能。
谁最适合多用户系统的整体性能？
【问题讨论】：
标签： sql database performance sorting
【发布时间】：2010-09-24 12:10:41
【问题描述】：
这取决于...是否涉及分页？数据集的最大大小是多少？整个数据集是否需要一直以相同的方式排序？还是根据用户选择？或者，（如果涉及分页）是否只需要对客户端屏幕上单页中的记录进行排序？ （通常不可接受）还是需要对整个数据集进行排序并重新显示新排序集的第一页？
与这种排序操作的处理要求相比，客户端硬件的分布情况如何？
底线是；应该控制您的决定的是整体用户体验（当然是根据成本来衡量的）...一般来说，客户端机器比服务器慢，并且可能会导致额外的延迟。 ... ...但是客户端在初始页面加载后多久会请求一次额外的自定义排序操作？ （客户端上已经存在的客户端数据比往返要快得多……） 但是在客户端排序总是需要在初始加载时将整个数据集发送到客户端......这会延迟初始页面显示......这可能需要延迟加载、AJAX 或其他技术复杂性来缓解......
在服务器 otoh 上进行排序，引入了额外的可扩展性问题，并且可能需要您向服务器场添加更多的盒子来处理额外的负载......如果您在数据库中进行排序并达到该阈值，这可能会变得复杂. （要在 DB 上横向扩展，您必须实现一些只读复制方案，或者其他一些允许多个服务器（每个都进行处理）共享只读数据的解决方案）..
【讨论】：
-
+1 以“取决于”开始答案 - 它总是取决于。
一般来说，你应该让数据库来做排序；如果它没有资源来有效地处理这个问题，你需要升级你的数据库服务器。
首先，数据库可能已经在您想要的字段上有索引，因此按排序顺序检索数据可能很简单。其次，客户端在获得所有结果之前无法对结果进行排序；如果服务器对结果进行排序，您可以一次处理一行，已经排序。最后，数据库可能比客户端机器更强大，并且可能更有效地执行排序。
【讨论】：
-
在台式机上使用高性能PC，托管DBMS的机器比客户端更强大并非定局。不过，我同意基本结论。
-
如果您连接了 1000 个客户端，那么拥有超级强大的数据库服务器就毫无意义。应用服务器或客户端可能功能较弱，但对它们的需求较少，因此总体上可能更快。否则，索引的响应是完全正确的。
-
@gbjbaanb - 我的想法正是
-
数据库可以同时处理1000个并发用户排序吗？例如像交易/外汇/股票应用程序。还是您会在每个并发用户上对客户端进行排序？
我更喜欢在客户端进行自定义排序，但我也建议大多数 SQL 语句默认应该有一些合理的 ORDER BY 子句。它对数据库的影响很小，但是如果没有它，您以后可能会遇到问题。很多时候，开发人员或用户在没有意识到的情况下会开始依赖一些初始的默认排序顺序。如果未指定 ORDER BY 子句，则数据仅按该顺序排列。在以后的某个日期，索引可能会更改或数据可能会重新组织，用户会抱怨，因为数据的初始顺序可能已经从他们下面改变了。
【讨论】：
与任何其他与性能相关的问题一样，通用答案是……“视情况而定”。但是，我已经开发出在客户端进行排序的偏好。我们编写基于浏览器的应用程序，我对客户端的定义分为 Web 服务器和实际的最终用户客户端，即浏览器。我有两个原因更喜欢在客户端排序而不是在数据库中排序。
首先，从设计的角度来看，存在“正确”位置的问题。大多数时候，数据的顺序不是业务规则的事情，而是最终用户方便的事情，所以我将其视为演示文稿的功能，我不喜欢将演示文稿问题推送到数据库中。也有例外，例如，某件商品的当前价格是存档的最新价格。如果您通过以下方式获得价格：
SELECT TOP 1 price
FROM itemprice
WHERE ItemNumber = ?
AND effectivedate <= getdate()
ORDER BY effectivedate DESC
那么行的顺序在很大程度上是业务规则的一部分，显然属于数据库。但是，如果您在用户按姓氏查看客户时按 LastName 排序，然后在单击 FirstName 列标题时再次按 FirstName 排序，当他们单击该标题时再次按 State 排序，那么您的排序是演示文稿的功能，并且属于表现层。
我更喜欢在客户端层进行排序的第二个原因是性能。 Web 服务器水平扩展，也就是说，如果我的 Web 服务器因用户而过载，我可以添加另一个，一个，另一个，另一个。我可以拥有尽可能多的前端服务器来处理负载，并且一切正常。但是，如果我使数据库过载，我就完蛋了。数据库是垂直扩展的，当然，你可以在问题上投入更多的硬件，但在某些时候成本会变得过高，所以我喜欢让数据库做它必须做的选择，让客户端做排序，这它可以很简单。
【讨论】：
如果排序只是装饰性的，并且客户正在获取整个数据集，我倾向于让客户处理它，因为它是关于演示的。
另外，比如说在网格中，您可能必须在客户端中实现排序，因为用户可能会通过单击列标题来更改排序（不想让服务器再次检索所有信息)
【讨论】：
总的来说，我同意上面表达的观点，即服务器端排序通常是要走的路。但是，有时需要进行客户端排序：
- 排序标准是用户可选择的或众多的。在这种情况下，向表中添加少量索引可能不是一个好主意 - 特别是如果插入性能是一个问题。如果某些排序标准很少使用，则索引不一定值得，因为插入次数会超过选择次数。
- 排序标准不能用纯 SQL [不常见] 表达，或者不能被索引。它不一定比客户端更快，但它会占用服务器的负载。
要记住的重要一点是，虽然理论上平衡强大的客户端和服务器之间的负载可能是一个好主意，但只有服务器可以维护一个索引，该索引在每次插入时都会更新。无论客户端做什么，它都是从一组未编入索引的未排序数据开始的。
【讨论】：
情况各不相同，衡量绩效很重要。
有时很明显 - 如果您有一个大数据集并且您对排序列表的一小部分感兴趣（例如，在 UI 应用程序中分页） - 在服务器上进行排序可以节省数据传输。
但通常你有一个 DB 和几个客户端，当客户端空闲时，DB 可能会过载。客户端上的排序并不繁重，在这种情况下它可以帮助您扩展。
【讨论】：
我赞成罗伯茨的回答，但我想补充一点。
我也喜欢在 SQL Server 中对数据进行排序，我曾在许多尝试在客户端进行排序的系统上工作过，几乎在每种情况下，我们都必须重新编写流程才能在 SQL 中完成服务器。你可能会问为什么会这样？我们有两个主要原因。
- 正在排序的数据量
- 由于#1 需要实现正确的分页
我们处理向用户显示大量数据的界面，并且利用 SQL Server 的强大功能来处理排序和分页比在客户端执行的性能要好得多。
为此，在我们的环境中将 SQL Server 端排序转换为客户端排序，两者都没有分页。客户端使用 XML 排序 28 秒，服务器端排序总加载时间 3 秒。
【讨论】：
像往常一样，“视情况而定”:)
如果您有一个存储过程，例如，将结果发送到您的表示层（无论是报表、网格等），那么您使用哪种方法可能并不重要。
不过，我通常遇到的是具有排序功能的视图（例如，因为它们被报表直接使用）但也被其他视图或其他具有自己排序功能的过程使用。
因此，作为一般规则，我鼓励其他人在客户端进行所有排序，并且只有在有合理理由的情况下才在服务器上进行。
【讨论】：