Entity Framework调用存储过程出现随机性延迟问题的排查求助

兄弟，你遇到的这个问题我太熟了——存储过程在SSMS里跑飞快，EF调用一开始也正常，过几天突然变慢，偶尔又自己恢复，这种摸不着头脑的情况大概率和执行计划缓存脱不了干系，尤其是你改了别名就恢复的细节，几乎实锤了这个方向。

先给你拆解下核心原因：SQL Server的执行计划缓存有时候会踩**参数嗅探（Parameter Sniffing）**的坑。当存储过程第一次执行时用的参数和后来常用的参数数据分布差异很大，生成的执行计划就不适合后续的调用，导致性能暴跌。而你修改别名相当于让SQL Server认为这是个新查询，被迫重新生成执行计划，所以暂时好了，但过几天缓存又可能因为新的参数嗅探或者统计信息过时，再次生成糟糕的计划。

下面给你几个实打实的解决方案，从临时应急到根治问题都有：

1. 从存储过程本身根治参数嗅探 #

这是最推荐的长期解决方案，直接从根源避免糟糕的执行计划缓存：

• 强制每次重新编译计划：在存储过程的查询末尾加OPTION (RECOMPILE)，让SQL Server每次执行都根据当前参数生成最优计划。虽然会有一点编译开销，但对于你这种时快时慢的场景，利远大于弊。示例：

  CREATE PROCEDURE ps_myProcStock
      @id INT
  AS
  BEGIN
      SET NOCOUNT ON;
      -- 你的查询逻辑
      SELECT * FROM YourStockTable WHERE Id = @id OPTION (RECOMPILE);
  END
  

• 基于统计信息生成计划：如果参数分布不均匀，但不想每次都编译，可以用OPTION (OPTIMIZE FOR UNKNOWN)，让SQL Server基于表的统计信息而不是具体传入的参数生成计划，兼容性更强：

  SELECT * FROM YourStockTable WHERE Id = @id OPTION (OPTIMIZE FOR UNKNOWN);
  

2. 临时清理执行计划（应急用） #

如果你暂时不想改存储过程，可以手动清理该存储过程的执行计划，而不是做没用的IISReset（IISReset重启的是应用池，和SQL Server的执行计划缓存完全没关系）：

-- 先找到存储过程对应的执行计划
SELECT plan_handle, st.text
FROM sys.dm_exec_cached_plans cp
CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
WHERE st.text LIKE '%ps_myProcStock%';

-- 用查到的plan_handle删除对应计划（替换成你自己的plan_handle值）
DBCC FREEPROCCACHE (0x06000500123456789ABCDEF);

注意：这只是临时解决，还是要尽快用方案1根治。

3. 检查EF的调用细节 #

确保EF没有帮你“添乱”：

• 开启EF的日志功能，查看实际发送给SQL Server的命令，确认和你在SSMS里执行的完全一致，排除参数传递或额外过滤的问题：

  // 在调用存储过程前添加日志输出
  db.Database.Log = message => Console.WriteLine(message);
  var result = db.ps_myProcStock(id).ToList();
  

• 确认EF生成的存储过程调用没有多余的包装，比如是不是误加了AsNoTracking()之外的不必要配置。

4. 更新表的统计信息 #

SQL Server的统计信息过时也会导致执行计划不准确。手动更新存储过程涉及表的统计信息：

UPDATE STATISTICS YourStockTable; -- 替换成你的实际表名

也可以确保SQL Server的自动更新统计功能开启（默认是开启的，但可以检查下）：

ALTER DATABASE YourDatabaseName SET AUTO_UPDATE_STATISTICS ON;

5. 排查其他潜在瓶颈 #

如果以上方法都没用，当调用变慢时，用下面的SQL查看当前请求的等待类型，排除锁等待、IO瓶颈等其他问题：

SELECT r.session_id, r.wait_type, r.wait_time, st.text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE r.session_id <> @@SPID;

比如如果wait_type是PAGEIOLATCH_SH，那可能是磁盘IO的问题，就需要从存储层面优化了。

总的来说，你改别名就恢复的现象，本质就是让SQL Server重新编译了执行计划，避开了之前缓存的糟糕计划。所以优先从存储过程层面解决参数嗅探问题，配合更新统计信息，应该就能彻底解决这种时快时慢的诡异情况了。

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