我的执行计划是想欺骗我吗？答案

【问题标题】：Is my execution plan trying to trick me?我的执行计划是想欺骗我吗？
【发布时间】：2009-12-29 21:11:04
【问题描述】：

我正在尝试加快我拥有的长时间运行的查询（运行大约需要 10 分钟......）。为了追踪查询的哪一部分花费我最多的时间，我在运行它时包含了实际执行计划，并发现一个占 55% 的特定部分（下面的屏幕截图）

alt text http://img109.imageshack.us/img109/9571/53218794.png

这对我来说似乎不太正确，所以我在这个麻烦部分之前和之后添加了 Print '1' 和 Print '2'。当我只运行查询 17 秒然后取消它时，我假设的 1 和 2 打印输出意味着它在前 17 秒内通过了该部分。

alt text http://img297.imageshack.us/img297/4739/66797633.png

是我做错了什么还是我的执行计划误导了我？

【问题讨论】：

你能提供完整的查询吗？
看起来您发布的内容不是查询的问题部分。看起来您要切断的内容更多......这就是问题所在。
为什么说我贴的部分不是查询的问题部分？我假设一个占 55% 的部分应该花费大约 10 分钟的一半来运行，我错了吗？您还使用哪些其他方法来确定查询的问题部分？
如果可以避免的话，我宁愿不在线发布整个查询。只用执行计划就不能找到问题部分吗？
通过查看执行计划可以弄清楚很多，但您只是展示了其中的一部分。此外，时间问题可能与查询成本没有直接关系。还有更多可能发生的事情；这就是为什么查看整个交易很重要的原因。

标签： sql sql-server sql-server-2005 sql-execution-plan

【解决方案1】：

来自 perfmon 的指标也有助于找出问题所在……您的 tempDB 所在的驱动器可能会遇到一些严重的 IO 问题。此外，运行跟踪并查看实际运行的 CPU 和 IO。

要查看的良好性能指标是磁盘队列长度（平均和写入）。

如果您无权访问 perfmon 或不想跟踪事物，请在查询开始时使用“SET STATISTICS IO ON”并让它完成...不要停止它。仅仅因为执行计划说它正在接管有成本并不意味着它将运行一半的查询时间......它可能更多（或更少）。

【讨论】：

【解决方案2】：

上面写着Query 10: Query cost (relative to the batch): 55%。是否 100% 肯定它是您用 Print 语句包围的批次中的第 10 个语句？ INSERT ... INTO #mpProgramSet2 是否可以多次执行，有时在 17 秒以下，有时 5 分钟，具体取决于选择/插入的数据量？

作为旁注，您应该使用SET STATISTICS TIME ON 运行而不是打印，这将为您提供批处理中每个语句的准确编译/时间和执行时间。

【讨论】：

是的，我很肯定。下次我会确保使用统计数据。可能会帮助我追踪这里发生的事情。
执行时间会因为数据变化而变化吗？此外，您必须确保每次都在热缓存上运行。如果您添加SET STATISTICS IO ON，您应该查看同一语句的逻辑读取和物理读取之间的差异。大量物理读取表示冷缓存（必须等待 I/O），而下一次执行可能只有逻辑读取和 0 次物理读取（意味着它找到了缓存在内存中的所有数据，不需要 I/O）。

【解决方案3】：

我不相信打印“1”和“2”会证明什么已经执行，什么没有执行。我做同样的事情，但我不会依赖它作为证据。您可以从第一个插入查询中打印@@rowcount - 这将确定插入已经发生。

虽然计划说查询可能会占用 55% 的成本，但可能不会占用 55% 的执行时间，尤其是在查询结果被缓存的情况下。

打印@@rowcount 的另一个优点是将实际行数与估计的行数（51K）进行比较。如果它们相差很大，那么您可以调查索引的统计信息。

【讨论】：

【解决方案4】：

我们需要完整的查询来了解发生了什么；但我可能会先将 MAXDOP 设置为 1，以限制它运行的处理器数量。

请注意，有时由于锁定等原因，查询需要仅限于 1 个处理器。

此外，您可以尝试将 NOLOCKs 添加到任何可以避免脏读的选择中。

【讨论】：

这是设置数据库的最大处理器还是我的查询？
仅用于此查询。 MAXDOP 0 表示使用所有处理器，MAXDOP 1 表示仅使用 1，MAXDOP 2 表示使用 2，依此类推