在存储过程执行方面调试SQL Server 2016中的一个奇怪场景

在我们的组织中，我们在Azure上拥有SQL Server VM，并始终保持2个节点的可用性组。在存储过程执行方面调试SQL Server 2016中的一个奇怪场景

场景：

我们一个程序叫“SP_xyz”，它包含一个选择具有几个内部联接获得证书持有者的列表查询。在一些负载之后，这个存储过程（SP）开始运行缓慢，因此我们已经优化了这个并将该SP重新投入生产，并且它运行良好一段时间。
经过几个月随着负载的增加，再次出现了这个SP中的缓慢问题，并且我们再次分析了这个SP并进行了优化。现在神秘来临，为了交叉验证新优化的SP，我们在生产中创建了与_test相同的SP。新的SP是“SP_xyz_Test”。
当我们在prod中运行这个新的_Test SP，其中旧SP（SP_xyz）运行缓慢的同一组参数时，新优化的SP以毫秒为单位给出了对几秒老SP的结果。
令我们惊讶的是，当我们运行旧SP时的下一个动作，它也开始以毫秒为单位给出结果。这真让我们感到害怕，因为所有这些问题都会出现在生产环境中，因为我们有大约300多个SQL存储过程。

我们做了分析，我们能想到的几件事情要找到问题的根源：

而且因为我们知道SP执行计划将特定于SP名称。但是，在这里，老SP如何变得更快是我们想知道的。

但是所有这些东西都已经安排好了，并且正在生产中运行，而旧SP开始运行缓慢。但新的_test SP运行的运动速度变得非常快。

我们在这里错过了什么，有没有人遇到过这个问题？

这实际上并不是我所要求的。这是在sql server中sprocs发生的非常基本的事情。我的问题是没有改变任何Sp可以更快开始执行的速度，只需在同一个数据库服务器上运行带有不同名称的优化sp。 – AnandPhadke

我认为参数嗅探可能是一个问题在这里 – TheGameiswar

@TT - 对不起，如果标题不summerize。我想到了我的标题。我将尝试修改 – AnandPhadke

我想与你所提供的细节，目前尚不清楚..但因为使用的是SQLSERVER 2016 ..你可以使用querystore随着时间的推移跟踪语句或存储过程的执行

的查询可能会有不同随着时间的推移计划和计划可能会表现更好，而且可能不会。因此，当您启用查询存储时，您可以查看回归查询部分中随时间推移的所有计划更改，这可以帮助您分析为什么一个计划花费的时间多于另一个..至少它的一个起点..

下面是一个查询与不同的计划（点代表新的计划随着时间的推移），并在图上绘制的地方表明所花费的时间

2017-10-06 07:53:48 TheGameiswar

这将有助于识别前后的查询计划。但在生产中，我们尚未启用查询存储库来捕获这些计划。所以我们没有与我们的统计资料来验证。但在此之前，如何改变查询计划是我的基本问题？ – AnandPhadke

查询计划更改可能会发生，原因很多..stats过时/统计重新编译，表更改..反编译提示..很少我知道 – TheGameiswar

确切，但所有这些事情都定期发生在服务器上，这个SP运行缓慢。我们用不同的名称（_test）测试优化后的sp的运动速度变得很快。 – AnandPhadke

不知道你是否得到了这个答案。

我想这是典型的执行计划因过程的动态性而过时的情况。

尝试recompile选项。

CREATE PROCEDURE SP_xyz 
WITH RECOMPILE 
AS 
BEGIN 
....... 
END 
GO

2018-01-22 01:50:23

我们试过这个，但没有运气..即使它工作，我们如何确保生产中有多少SP需要定期重新编译..这也不可行。因为我们不能使用这个选项所有运行缓慢的SP作为存储过程的整体思想在性能方面都受到影响。 – AnandPhadke

回答