我正在分析（SQL Server 2008）我们的一些视图和查询，以确定它们在CPU使用率和读取方面的效率。我理解Reads是8KB页面中逻辑磁盘读取的数量。但我很难确定我应该满意的是什么。
例如，当我查询我们的一个视图，而这些视图又与另一个视图连接并且有三个具有表值UDF的OUTER APPLY时，我得到的读取值为321，CPU值为0.我首先想到的是我应该对此感到高兴。但我该如何评估321的价值呢？这告诉我在逻辑上读取了2,654,208个字节的数据以满足查询（返回单行和30列）。
你们中的一些人如何确定这是否足够好，还是需要更多微调？你会用什么标准？
另外，我很好奇在读取的2,654,208字节的逻辑数据中包含了什么。这是否包括返回的单行中30列中包含的所有数据？
答案 0 :(得分：5)
321读取CPU值为0听起来不错，但这一切都取决于。
此查询的运行频率如何？为什么使用表返回UDF而不是仅仅进行连接？数据库使用的上下文是什么（有多少用户，每秒事务数，数据库大小，是OLTP还是数据仓库）？
额外的数据来自：
页面中的所有其他数据都需要满足执行计划中的读取。请注意，这包括聚簇索引和非聚簇索引。检查执行计划将使您更好地了解正在阅读的内容。您将看到对各种索引和表的引用，以及是否需要搜索或扫描。请注意，扫描意味着读取整个索引或表中的每个页面。这就是为什么寻求比扫描更合适的原因。
表INNER中的所有相关数据在视图中加入，无论是否需要这些JOIN来为您正在执行的查询提供正确的结果，因为优化器不知道这些INNER JOIN将会或在加入行之前不会排除/包含行。
如果您按要求提供查询和执行计划，我可能会给您更好的建议。由于您正在使用表值UDF，我还需要查看UDF本身或至少UDF的执行计划（这可能只是通过撕掉它的肉并在函数上下文之外运行，或者将其转换为存储过程）。
答案 1 :(得分：5)
2.5MB包括321页中的所有数据，包括与查询检索的页面相同的其他行，以及为查找数据而检索的索引页。注意，这些是逻辑读取，而不是物理读取，例如，从缓存页面读取将使读取更加“便宜” - 在优化时也需要CPU和分析器成本指标。
w.r.t。如何确定读数的最佳“目标”。
FWIW我将实际读数与最佳值进行比较，我认为这是在“完美”世界中返回查询中数据所需的最小页数。
e.g。如果你从表x中每页计算大约5行，并且你的查询返回20行，那么“完美”读取次数将是4，加上导航索引的一些开销（当然假设这些行是“完美的”聚类为你的查询） - 所以乌托邦就会说5-10页。
对于性能关键查询，您可以使用实际读取与'乌托邦'读取进行微优化，例如：
您可能会发现this article有用
HTH！