我正在尝试加快我拥有的长时间运行的查询（运行大约需要 10 分钟......）。为了追踪查询的哪一部分花费我最多的时间，我在运行它时包含了实际执行计划，并发现一个占 55% 的特定部分（下面的屏幕截图）
替代文字 http://img109.imageshack.us/img109/9571/53218794.png
这对我来说似乎不太正确，所以我在这个麻烦部分之前和之后Print '1'添加了。Print '2'当我运行查询仅 17 秒然后取消它时，我假设的 1 和 2 打印输出意味着它在前 17 秒内通过了该部分。
替代文字 http://img297.imageshack.us/img297/4739/66797633.png
我在这里做错了什么还是我的执行计划误导了我？
来自 perfmon 的指标也将有助于找出问题所在……您的 tempDB 所在的驱动器可能会遇到一些严重的 IO 问题。此外，运行跟踪并查看实际运行的 CPU 和 IO。
要查看的良好性能指标是磁盘队列长度（平均和写入）。
如果您无权访问 perfmon 或不想跟踪事物，请在查询开始时使用“SET STATISTICS IO ON”并让它完成......不要停止它。仅仅因为执行计划说它正在接管有成本并不意味着它将运行一半的查询时间......它可能更多（或更少）。
它说Query 10: Query cost (relative to the batch): 55%。是否 100% 肯定它是您用 Print 语句包围的批次中的第 10 个语句？INSERT ... INTO #mpProgramSet2 是否可以多次执行，有时在 17 秒以下，有时 5 分钟，具体取决于选择/插入了多少数据？
作为旁注，您应该运行SET STATISTICS TIME ON而不是打印，这将为您提供批处理中每个语句的确切编译/时间和执行时间。
我不相信打印“1”和“2”会证明什么已经执行，什么没有执行。我做同样的事情，但我不会依赖它作为证据。您可以从第一个插入查询中打印@@rowcount - 这肯定表明插入已经发生。
虽然计划说查询可能会占用 55% 的成本，但可能不会占用 55% 的执行时间，尤其是在查询结果被缓存的情况下。
打印@@rowcount 的另一个优点是将实际行数与估计的行数（51K）进行比较。如果它们相差很大，那么您可以调查索引的统计信息。
我们需要完整的查询来了解发生了什么；但我可能会先将 MAXDOP 设置为 1，以限制它运行的处理器数量。
请注意，有时由于锁定等原因，查询需要仅限于 1 个处理器。
此外，您可以尝试将 NOLOCKs 添加到任何可以避免脏读的选择中。
