我有一个存储过程，返回一组8个integer值。在开始时，所有似乎都以正确的方式执行，但是在执行一些后，当我使用TADOQuery在我的C ++代码中执行它时，执行时间会增长但不会在SSMS中执行时间仍然正确。
在第一步中，我尝试改进我的存储过程以使其更具有性能意识。我赚了一些执行时间，但问题仍然存在。
我还尝试检查我的代码，搜索一些可能会延长执行时间的荒谬行。但我使用与其他存储过程相同的代码，但它们没有显示相同的效果。
所以我使用SQL Profiler来看看到底发生了什么。下面你可以看到一个好的执行和一个坏的执行之间的差异。
好执行
CPU | Reads | Writes | Duration
93 | 13657 | 0 | 113
执行不好
CPU | Reads | Writes | Duration
22090 | 31960629 | 0 | 25158
正如您所看到的，读取和cpu访问的值呈指数级增长。
如果我在SSMS查询编辑器中执行相同的存储过程，结果将直接执行到良好的执行。
我只是希望我的存储过程总是以大致相同的持续时间执行，无论我在哪里执行查询。
已经好几次见过 - 它吸引了我们很多人。针对您的呼叫检查设置，例如ansi nulls on / off，其他设置等。这样的更改会导致不同的执行计划。有关详细信息，请参阅SQL faster in ssms than in application。
问题出在执行计划中。
编译存储过程时，将确定基于实际数据的新计划。在几次执行之后，计划变得陈旧，因为数据经常变化。
所以为了实现这个问题，我使用了WITH RECOMPILE选项来存储过程。我认为这不是最好的解决方案，但它解决了问题，现在我不再有查询超时了。
通过这种方式，我尝试了一些其他解决方案，以便在最佳时刻应用重新编译，但唯一可行的解决方案是使用此选项。