SQL Server查询计划分析

Question

我在我正在监视的服务器上运行了布伦特·奥扎尔工具包中的sp_BlitzCache脚本(我在该公司工作了大约3周)。该过程的结果具有以下值：

╔═════════╦═════════════╦═══════════════════╦══════════════════╦════════════════╦══════════════╦════════════╦═════════════════════╦═══════════════════╦═════════════════╦═════════════╦═══════════╦═════════════╗
║  Cost   ║ #Executions ║ Executions/Minute ║ Execution Weight ║ Total CPU (ms) ║ Avg CPU (ms) ║ CPU Weight ║ Total Duration (ms) ║ Avg Duration (ms) ║ Duration Weight ║ Total Reads ║ Avg Reads ║ Read Weight ║
╠═════════╬═════════════╬═══════════════════╬══════════════════╬════════════════╬══════════════╬════════════╬═════════════════════╬═══════════════════╬═════════════════╬═════════════╬═══════════╬═════════════╣
║ 47,4959 ║      212068 ║ 416,6365          ║ 10,9146          ║ 21883508.2710  ║ 103.1910     ║ 61,4143    ║ 47839177.6180       ║ 225.5841          ║ 73,0647         ║ 15372027688 ║     72486 ║ 66,6277     ║
╚═════════╩═════════════╩═══════════════════╩══════════════════╩════════════════╩══════════════╩════════════╩═════════════════════╩═══════════════════╩═════════════════╩═════════════╩═══════════╩═════════════╝

我取了这些值，大约下午4点我有一列显示该计划是在上午8点左右创建的(8小时窗口)。

我验证了total reads值= "15372027688“。这个是可能的吗？在8小时的时间里，我有大约150亿的阅读量？我的CPYU权重值为61,4143，成本= 47,4959。

有谁能更好地向我解释这个查询的成本，它意味着什么？是关于并行性的成本阈值吗？

还具有运行过程的警告：

警告

• 失踪指数(3)
• 并行
• 底层CE (数据库在Server 2014实例上运行时处于兼容级别110 )，并且正在运行OUTSYSTEMS数据库)

我还在服务器上运行性能计数器，并与server实例有大约1400个连接。在网络适配器流量上，我的总字节约为92000,000，00/秒。

Answer 1

欢迎来到堆栈交换。一般情况下，你应该尽量把你的问题限制在一个单一的，明确的问题上.在这里，您只需要为您的服务器提供一般的调优帮助，而这并不是最适合站点的。理想的情况是，问答对广大受众是有用的，而且随着时间的推移也将保持相关性。综上所述，我将回答关于逻辑读取的数量和查询成本的重要性的两个离散问题。

当然，在一个服务器上有150亿个读取的时间超过8个小时是可能的。这些读取是逻辑读取，表示对内存的操作，而不是磁盘。我刚刚在我的桌面上运行了一个随机查询，它可以立即执行大约200万次逻辑读取。推断出来会让我在8个小时内总共读580亿条逻辑数据。

查询成本是SQL Server执行查询所需完成的预期工作量的统一度量。一般来说，如果没有上下文，这个数字并不意味着什么，除非有问题，否则你不必担心它。如果你对此感兴趣的话，发动机会以不同的方式使用它。下面是我从头上知道的清单：

• 如果查询成本太低，则不符合并行计划的要求。这是由并行代价阈值选项控制的。
• 查询在抛出错误之前等待内存授予的秒数。这里有一些可能影响它的配置选项，但一般的公式是查询成本/ 25 (以秒为四舍五入)，最长为86400秒(1天)。
• 优化器在创建查询计划期间所采取的步骤的数量。优化器可能在评估可能的查询计划方面做更多的工作，而这些查询的成本预计会更高。
• 如果将查询发送到小查询资源信号量。
• 如果由于查询调控器成本限制而无法运行查询。

一般来说，除非出了什么问题，否则你不必担心这些细节。但是，有几种常见的情况下，查询成本可能是有用的。如果某些查询不是并行的，或者太多的查询是并行的，那么您可能需要根据您的工作负载来调整CTFP。如果查询速度慢，并且您能够找到一个查询提示，使得查询速度比两个查询之间的成本差更快，则可以提供有用的线索，说明为什么优化器没有自然地选择您所暗示的查询计划。如果查询速度非常慢，成本非常慢(例如，<1单位)，这意味着优化器正在处理错误的信息。例如，基数估计值可能相差甚远。如果你能纠正这个坏消息，你可能会得到一个更有效的计划。