sql-server - SQL Server Profiler - 评估读取。什么被认为是 'good' 或 'bad' ？

Question

我正在分析(SQL Server 2008)我们的一些 View 和查询，以确定它们在 CPU 使用率和读取方面的效率。我知道读取是 8KB 页面中的逻辑磁盘读取数。但我很难确定我应该对什么感到满意。

例如，当我查询我们的一个 View ，该 View 又与另一个 View 连接并具有三个带有表值 UDF 的 OUTER APPLY 时，我得到 321 的 Reads 值，CPU 值为 0。我的第一个想法是我应该对此感到高兴。但是我如何评估 321 的值呢？这告诉我从逻辑上读取了 2,654,208 字节的数据以满足查询(返回单行和 30 列)。

你们中的一些人会如何确定这是否足够好，或者需要更多的微调？你会用什么标准？

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

Answer 1

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

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

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

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

对于性能关键查询，您可以使用实际读取与“乌托邦”读取进行微优化，例如:

我是否可以在集群(表)中每页容纳更多行，例如用 varchar() 而不是 char，或使用 varchar 而不是 nvarchar() 或使用较小的整数类型等替换未搜索的字符串

是否可以更改聚集索引以减少需要获取的页面(例如，如果上述查询的 20 行分散在不同页面中，则读取次数将 > 4)

如果失败(因为您只能进行一个 CI)，覆盖索引是否可以完全取代访问表数据(集群)的需要，因为适合您查询的覆盖索引将具有更高的“行”密度

对于索引，密度改进(例如填充因子或索引的更窄索引)可能意味着更少的索引读取

您可能会发现 this article有用

哼!