Azure数据库存储过程ASP.NET提速但SSMS仍缓慢问题咨询

这情况我之前也碰到过，核心矛盾是同一存储过程在不同客户端（ASP.NET vs SSMS）执行效率差异巨大，哪怕已经创建了优化索引。下面是几个最可能的原因和对应的排查/解决办法：

1. 数据库端的执行计划缓存没更新 #

你重启了SSMS，但数据库服务器上的执行计划缓存可能还保留着创建索引前的旧计划（这个计划没用到新索引，所以依然慢）。试试这两个操作：

• 执行存储过程时强制重新编译：EXEC YourStoredProcedureName @Param1 = 'xxx' WITH RECOMPILE;，看看这次是不是能用到新索引，速度提上来。
• 如果确认是缓存的问题，可针对性清理该存储过程的缓存（比全局清缓存更安全）：

  DECLARE @PlanHandle VARBINARY(64);
  SELECT @PlanHandle = plan_handle FROM sys.dm_exec_procedure_stats WHERE object_id = OBJECT_ID('YourStoredProcedureName');
  DBCC FREEPROCCACHE(@PlanHandle);
  

  之后再执行存储过程，应该会生成基于新索引的执行计划。

2. ASP.NET与SSMS的默认SET选项不一致 #

不同客户端工具的默认SET配置（比如ANSI_NULLS、QUOTED_IDENTIFIER、ARITHABORT等）会影响SQL Server选择执行计划。如果ASP.NET和SSMS的SET选项不一样，可能导致生成的执行计划完全不同。

• 在SSMS里执行：DBCC USEROPTIONS;，记录下所有选项的值。
• 在ASP.NET代码里，执行同样的DBCC USEROPTIONS;（比如在调用存储过程前执行，把结果打出来）。
• 对比两者的差异，把SSMS的SET选项改成和ASP.NET一致，比如如果ASP.NET里ARITHABORT是ON，而SSMS默认是OFF，就在SSMS里先执行SET ARITHABORT ON;，再执行存储过程试试。

3. 参数嗅探导致的执行计划不匹配 #

如果你的存储过程带参数，可能存在参数嗅探问题：ASP.NET调用时用的参数值刚好适合新索引，所以生成了高效计划；而你在SSMS测试时用的参数值，触发了之前生成的低效计划（或者SQL Server嗅探到的参数和实际执行的参数不匹配）。

• 先确认你在SSMS里用的参数和ASP.NET里的是否完全一致，用相同参数执行试试。
• 如果参数差异是不可避免的，可以在存储过程里加入OPTION (RECOMPILE)，让SQL Server每次执行都生成最优计划（适合参数变化大的场景）；或者把参数赋值给存储过程内部的局部变量，避免SQL Server直接嗅探传入参数。

4. 额外排查点：SSMS的执行模式 #

有时候SSMS的“包含实际执行计划”、“统计信息时间”这些选项会增加额外开销，但你说耗时35秒，这个影响应该不大。不过可以试试关闭这些选项后再执行，排除干扰。

总结下来，最可能的原因是旧执行计划缓存未清理或者客户端SET选项不一致，先从这两点入手排查，应该能解决问题。

内容的提问来源于stack exchange，提问作者Liudi Wijaya