SQL Server Profiler - 评估读取。什么被认为是“好”还是“坏”？

Question

我正在分析（SQL Server 2008）的一些视图和查询，以确定它们的CPU使用率和读取效率。我明白Reads是8KB页面中逻辑磁盘读取次数。但是我很难确定我应该满意的。

例如，当我查询其中一个视图，该视图依次与另一个视图连接并具有三个带有表值UDF的OUTER APPLY时，我得到的读值为321，CPU值为0.我的第一个想法是我应该对此感到高兴。但我如何评估321的价值？这告诉我2654208字节的数据被逻辑读取以满足查询（返回单行和30列）。

你们会如何去决定这是否足够好，或者需要更多的微调？你会使用什么标准？

此外，我很好奇什么是包含在2,654,208字节的逻辑数据读取。这是否包括返回的单行中的30列中包含的所有数据？

Answer 1

2.5MB包含了321页中的所有数据，包括与为查询检索的页面相同的页面中的其他行，以及为检索数据而检索到的索引页。请注意，这些是逻辑读取，而不是物理读取，例如从缓存页面读取会使读取更“便宜” - 优化时还需要CPU和分析器成本指标。

w.r.t.如何确定读取的最佳“目标”。

FWIW我将实际读数与最佳值进行比较，我认为这是在“完美”世界中返回查询中所需数据所需的最小页数。

例如如果您从表x中每页计算大约5行，并且您的查询返回20行，则“完美”读取次数将为4，再加上一些导航索引的开销（假设当然行的聚集“完美”查询） - 所以乌托邦会在5-10页左右。

对于性能关键查询，可以使用实际的读取VS“乌托邦”读取到微优化，例如：

• 是否我所用的簇（表）适合每页更多的行，例如用varchar（）不用char替换未被搜索的字符串，或用varchar不用nvarchar（）或用较小的整数类型等。
• 是否可以改变聚集索引，以便需要获取更少的页面（例如，如果20上述查询的行分散在不同的页面上，然后读取将会是> 4）
• 如果失败（因为您只能有一个配置项），覆盖索引是否可以替代需要转到表数据（群集）由于覆盖索引适合您的查询将有更高的“行”密度
• 而对于指数，密度的改进，如填充因子或窄索引的索引可能意味着更少的索引读

您可能会发现this article有用

HTH！

Answer 2

321读取CPU值为0听起来不错，但这一切都取决于。

此查询运行的频率如何？为什么使用表返回的UDF而不是仅仅进行联接？数据库使用的上下文是什么（有多少用户，每秒事务数量，数据库大小，是OLTP还是数据仓库）？

额外的数据读取来自：

• 在满足读取执行计划完成所需的页面的所有其他数据。请注意，这包括聚簇索引和非聚簇索引。检查执行计划可以让你更清楚地知道究竟在读什么。您将看到对各种索引和表格的引用，以及是否需要查找或扫描。请注意，扫描意味着读取了整个索引或表中的每个页面。这就是为什么寻求扫描是可取的。

• INNER表中的所有相关数据连接到视图中，无论这些JOIN是否需要为您正在执行的查询提供正确的结果，因为优化程序不知道这些INNER JOIN将会或获胜排除/包含行直到它加入它们。

如果您按要求提供查询和执行计划，我可能会给你更好的建议。由于您使用的是表值UDF，因此我还需要查看UDF本身或至少UDF的执行计划（这可能是通过撕掉其肉并在函数上下文外部运行，或者将其转换为存储过程）。