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

Question

在我们的组织中，我们在 Azure 上拥有 SQL Server VM，并且始终位于具有 2 个节点的可用性组中。

场景：

1. 我们有一个名为“SP_xyz”的过程，它包含一个选择查询，其中包含很少的内部连接来获取凭证持有者列表。在一些负载之后，这个存储过程 (SP) 开始运行缓慢，因此我们对此进行了优化，并将该 SP 重新投入生产，它运行了一段时间。

2. 几个月后随着负载的增加，这个 SP 再次出现缓慢问题，我们再次分析了这个 SP 并进行了优化。现在谜团来了，为了交叉验证新优化的 SP，我们在生产中使用 _test 创建了相同的 SP。新的 SP 是“SP_xyz_Test”。

3. 当我们使用与旧 SP (SP_xyz) 运行缓慢的相同参数集在 prod 中运行这个新的 _Test SP 时，新优化的 SP 以毫秒为单位给出结果，而旧 SP 的结果是几秒钟。

4. 令我们惊讶的是，当我们运行旧 SP 的下一个动作时，它也开始以毫秒为单位给出结果。这真的让我们感到害怕，因为我们有大约 300 多个 SQL 存储过程。

我们确实分析了一些我们可以想到的事情来找到根本原因：

1. 索引重建
2. 统计更新

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

但所有这些事情都已安排好并在生产中运行，旧的 SP 开始运行缓慢。但是新的_test SP跑的动作，已经变得非常快了。

我们在这里遗漏了什么吗？以前有人遇到过这个问题吗？

Answer 1

我认为您提供的详细信息尚不清楚..但是由于您使用的是 sqlserver 2016.. 您可以使用 querystore 来跟踪语句或存储过程的执行情况

随着时间的推移，一个查询可能有不同的计划，一个计划可能执行得更好，一个可能不会。所以当您启用查询存储时，您可以在回归查询部分看到所有计划随时间的变化，这可以帮助您分析为什么一个计划比另一个计划花费更多时间..至少它是一个起点..

以下是具有不同计划的查询（点表示随着时间推移的新计划）以及图表上绘制的位置表示所用时间

Answer 2

不确定您是否得到了答案。

我想这是典型的执行计划过时的例子，因为你的过程是动态的。

试试recompile 选项。

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