所以基本上我有这个相对较长的存储过程。基本的执行流程是将SELECTS INTO一些数据放入带有他的#符号声明的临时表中,然后在这些表中运行游标,然后将“运行总计”生成到使用以下方法创建的第三个临时表中CREATE。然后,将所得的临时表与数据库中的其他表联接,以在进行某些分组等之后生成结果。问题在于,此SP一直运行良好,直到现在在1-2分钟内返回结果。现在突然需要12到15分钟。如果我从SP中提取查询并通过手动设置相同的参数在Management Studio中执行查询,则它会在1-2分钟内返回结果,但是SP花费的时间很长。任何想法都可能发生。我试图生成查询和SP的实际执行计划,但是由于游标而无法生成它。知道SP为什么要花这么长时间而不查询吗?
SELECTS INTO
#
CREATE
有几种可能的修复方法,包括将WITH RECOMPILE添加到您的存储过程中,这种方法的工作时间大约是一半。
在大多数情况下(尽管这取决于查询和sproc的结构),建议的解决方法是 不要 在查询中直接使用参数,而是将其存储在局部变量中,然后在查询中使用这些变量。