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