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