背景
我被要求确定两个查询中哪一个更适合我们的解决方案。粗略的 KPI 是我在用户屏幕上显示信息的速度(假设所有用户具有相同的 ping)。两个查询返回相同的数据,但构建方式却截然不同。启用客户端统计并为每个查询运行 10 次试验后,我开始比较他们的平均时间统计。
为了简单起见,我会说查询 A 的“服务器回复等待时间”较短,但由于“客户端处理时间”较高,因此“总执行时间”较高。
现在我正在尝试了解这些结果,以便我可以就应该推荐这两个查询中的哪一个做出更明智的决定。
问题
从一个客户端 (SSMS) 切换到另一客户端(产品中使用的客户端)时,预期会有多大差异?是否非常小(+/- 5%),或者客户端的变化是否可以将“客户端处理时间”改变 2 倍或更多(100% +)?
我问是因为我想知道是否应该使用“总执行时间”来比较两个查询的效率(b/c“客户端处理时间”和“服务器回复的等待时间”几乎没有差异或没有差异当在我们的产品中运行相同的查询时)或者我是否应该相互独立地比较这两个指标(“客户端处理时间”和“服务器回复的等待时间”),因为切换客户端时差异很大(即客户端处理时间可能会波动) 2 倍或更多,并将在投入生产时主导“总执行时间”)?
虚拟示例
查询 | 客户处理时间 | 服务器回复的等待时间 | 总执行时间 |
---|---|---|---|
A | 7000 | 1000 | 8000 |
B | 3500 | 2000 | 5500 |
如果我假设当我在 SSMS 之外运行这些值时它们不会有很大差异,那么我应该使用查询 B(较低的总执行时间)。
如果“客户端处理时间”的方差变化很大,那么我需要运行实验来确定 SSMS 和我们的工具之间的“客户端处理时间”比率是多少,然后再决定哪个更有效。
我理解的术语定义
服务器回复的等待时间:通常与等待服务器处理查询并发回响应所花费的时间有关。这可以包括服务器执行的数据检索、联接和聚合等操作。索引扫描、聚集索引扫描、表扫描和哈希匹配(用于连接)等运算符是服务器端处理的常见指标。
客户端处理时间:通常包括解析、聚合、排序和渲染结果集等客户端操作所花费的时间。这些操作通常由排序、计算标量、过滤器和远程查询(如果适用)等运算符表示。
从一个客户端 (SSMS) 切换到另一客户端(产品中使用的客户端)时,预期会有多大差异?是否非常小(+/- 5%),或者客户端的变化是否可以将“客户端处理时间”改变 2 倍或更多(100% +)?
深入研究这里的技术,您的问题实际上如下:
“如果我从 SSMS 运行查询,然后从其他客户端代码运行它,服务器会使用类似的执行计划吗?”
答案通常是是。您几乎可以肯定地假设答案是肯定的,以便优化您提到的查询。在 SSMS 中进行优化工作和测量,结果将在您的应用程序中有效。
但在某些情况下答案可能是否定的,我们将其称为边缘情况。如果查询位于存储过程中,则编译存储过程可以“准备”语句并将准备好的语句与其余可执行语句一起存储。同样,如果您的应用程序代码准备了语句并长时间保留在准备好的语句上下文上,您可能会遇到边缘情况。 如果表中的数据在语句准备和语句执行之间变化太大,以至于保存的执行计划变得异常缓慢,则边缘情况会给您带来问题。如果发生这种情况,重新编译您的存储过程或重新启动长时间运行的应用程序。