我在SQL Server 2008 R2 Express上测试存储过程。最终它将在完整版的SQL Server 2008 R2上运行。
在Management Studio中测试存储过程我注意到在还原数据库或重新启动SQL Server服务后第一次运行它时，该过程大约需要35秒才能运行。第二次以及随后一眨眼就完成了。
由此我假设查询计划需要一段时间才能创建。症状似乎与导致重新创建查询计划的原因相匹配。
我的问题是当我从C＃应用程序执行这个存储过程时，如果它超过30秒超时。我想我已经想出了如何增加超时但是从我读过的所有线程中人们都会说，除了特殊情况外，30秒应该是大量的时间。 ＆＃34;修复问题不要增加超时＆＃34;。
由于此存储过程每月只运行一次，因此每次使用它时都会创建一个新的查询计划。
我的其他任何存储过程都没有此问题。
关于诊断真实问题的最佳方法的任何想法？
该过程并不是非常复杂，它从几个连接的表中读取，并根据一些条件将大约4000行插入到另一个表中。 我不是世界上最好的SQLer，所以也许我做了一些愚蠢的事情。
我无法在数据库或其他任何内容中添加索引，因为它属于外部公司编写的业务应用程序。因此，我非常谨慎地做出任何改变，因为它可能导致其他不可预见的问题。
如果您认为值得在此处发布我的SQL代码，请告诉我。
由于 大卫
答案 0 :(得分：0)
看起来我回答了自己的问题。 我点击了小小的＆＃34;显示估计查询计划＆＃34; Management Studio中的按钮，并查看了查询计划。在很好的大字母中，它建议我为表添加一个索引，并为我提供了我需要用来创建它的索引名称的确切代码。我看了看那张桌子，里面有300多万行。在今天的条款中不是很多，但如果你必须在尝试创建查询计划时必须继续阅读它，这显然是一个问题。
无论如何，我创建了索引并再次运行我的应用程序，我无法重现该问题。它每次都像子弹一样运行。
我想我只需要考虑添加索引的后果。 首先是给它一个外部公司永远不可能复制的名称。 ：）
感谢所有花时间阅读我的帖子的人，我希望这个答案可以帮助其他人。
大卫