SSMS v17.4调试存储过程时修改后仍显示旧版本的解决办法咨询

我太懂这种糟心的感觉了——明明刚改完存储过程，调试单步执行时却还是跑旧代码，DBCC FreeProcCache时灵时不灵，总不能每次都重启SSMS吧？下面几个亲测有效的方法，比重启高效多了，你可以挨个试试：

• 精准清除目标存储过程的缓存，别全局清空
  全局的DBCC FreeProcCache不仅可能影响其他正在运行的业务，还不一定能精准命中你修改的那个存储过程。换个更精准的方式：先找到目标存储过程的缓存计划，再单独清除它：

  -- 先查询目标存储过程的缓存条目
  SELECT plan_handle, cacheobjtype, objtype, text
  FROM sys.dm_exec_cached_plans
  CROSS APPLY sys.dm_exec_sql_text(plan_handle)
  WHERE text LIKE '%你的存储过程名称%';
  
  -- 把查到的plan_handle替换进去，清除对应缓存
  DBCC FREEPROCCACHE(替换成上面查到的plan_handle值);
  

  这种方式只针对目标对象操作，不会干扰其他进程，精准度更高。

• 用sp_recompile强制存储过程重新编译
  这是专门为这类场景设计的命令，它会标记目标存储过程为「需要重新编译」，下次执行（包括调试）时就会自动加载最新版本：

  EXEC sp_recompile N'你的存储过程完整名称（比如dbo.YourProcName）';
  

  这个操作比全局清缓存轻量得多，而且直接针对目标对象，生效概率非常高。

• 关闭当前查询窗口，重新开新窗口调试
  有时候SSMS的单个查询窗口会缓存旧的存储过程元数据，哪怕数据库里的版本已经更新，当前窗口的调试上下文还是停留在旧版本。关掉当前窗口，重新打开一个新的查询窗口再启动调试，往往就能直接加载新代码，比重启整个SSMS快太多。

• 检查是否有跟踪工具锁定了缓存
  如果你的环境里开启了SQL Server Profiler或者Extended Events跟踪，某些跟踪规则可能会锁定缓存计划，导致新的编译无法生效。可以暂时停止这类跟踪，再尝试重新调试。

要是以上方法都试过还是不行，那可能是SSMS v17.4本身的老版本bug了，这时候重启SSMS确实是最后的办法，但前面几个方法大概率能帮你解决问题，不用每次都大动干戈。

内容的提问来源于stack exchange，提问作者Graham Reavey