我有一个处理大量数据的存储过程（在这个例子中大约有 5m 行）。性能差异很大。我已经让这个过程在短短 15 分钟内运行，并且看到它运行了长达 4 小时。
为了维护，并且为了验证逻辑和处理是否正确，我们将 SP 分成几个部分：
TRUNCATE并填充一个工作表（索引），我们稍后可以使用自动化测试工具进行验证。
将几个表连接在一起（包括其中一些工作表）以生成另一个工作表
重复 1 和/或 2，直到产生最终输出。
我担心的是这是一个单一的 SP，因此在第一次运行时会得到一个执行计划（甚至WITH RECOMPILE）。但当时，工作表（Work 模式中的永久表）是空的。
我担心，无论索引方案如何，执行计划都会很差。
我正在考虑拆分 SP 并从其中调用单独的 SP，以便在构建工作表中的数据后，它们可以利用重新评估的执行计划。我还看到了使用 EXEC 运行动态 SQL 的参考，显然也可能得到一个RECOMPILE。
我仍在尝试获得SHOWPLAN许可，所以我很盲目。
您是否能够确定是否存在任何锁定问题？您是否在足够小的事务中运行 SP？
将其分解为子程序应该没有任何好处。
有人应该关心您的生产力，在没有基本优化资源的情况下工作。这表明可能还有其他可能的看不见的问题。
在下面的链接中获取“剖析执行计划”的免费副本，也许您可以从中获得一两个提示，这将使您对 SP 背后的真实情况有所了解。
http://dbalink.wordpress.com/2008/08/08/dissecting-sql-server-execution-plans-free-ebook/
您确定您看到的可变性是由“糟糕的”执行计划引起的吗？这可能是一个原因，但可能还有许多其他原因：
您是否尝试过多次使用相同的数据运行 SP？
此外，为了找出导致运行时/可变性的原因，我会尝试进行一些详细的测量以将问题归结为代码的特定部分。（最简单的方法是在 sp 的各个点插入一些日志调用）。然后尝试解释为什么该部分很慢（除了“5M 行;-)）并找出一种方法来加快速度。
目前，我认为在走“拆分 sp”路线之前有几个问题需要回答。
您是对的，在您从整个流程的多次执行中获得“实际”执行计划之前，您很难清楚地了解幕后发生的事情。
也许要考虑一点。您的工作表是物理的临时表吗？如果它们是物理的，您将通过将新数据插入没有索引（即堆）的新表中来获得性能提升，然后您可以在插入所有数据后在其上构建索引。
另外，您的过程的目的是什么。听起来您正在移动相当多的数据，在这种情况下，您可能希望考虑使用分区。您可以相对轻松地将数据输入和输出到主表。
希望我详细说明的内容很清楚，但请随时提出进一步的问题。
干杯，约翰
在某些情况下，我已经看到执行时间/查询计划的这种多样性程度归结为统计数据。我建议在运行进程之前针对您正在使用的表运行一些更新统计信息的测试。这将强制通过 SQL 重新评估执行计划，并且我怀疑会为您提供更一致的结果。此外，您可能会很好地查看执行时间的差异是否与您的 dbas 重新索引作业相关。也许您还可以在每次运行之前收集一些索引健康统计信息。
如果不是，正如其他回答者所建议的那样，您更有可能遇到锁定和/或争用问题。
祝你好运。
我能想到的唯一一件事是，当没有数据时，执行计划会出错，因为使用表扫描而不是索引是错误的，因为当整个表都可以放入内存时，表扫描速度非常快。由于创建执行计划时没有数据，您是否实际观察到或肯定正在发生其他负面影响？
您可以在查询中强制使用索引...
在我看来，你可能走错了路。
这是某种形式的输入或输出，还是您正在创建报告？如果是提要，我建议您更改流程以使用 SSIS，它应该能够非常快速地移动 500 万条记录。