.NET/F#中重复执行简单SqlCommand出现超时问题

以下是几种可能导致该问题的常见原因及对应排查/解决思路：

1. 参数嗅探（Parameter Sniffing）问题 #

SQL Server会缓存首次查询的执行计划，后续执行直接复用。若前两次传入的startDate对应数据量极小，生成的执行计划是针对小数据集优化的；第三次传入的日期对应数据量极大时，复用该计划会导致性能暴跌。而SSMS的会话设置（如默认开启SET ARITHABORT ON）可能会触发重新编译，或生成适配大数据集的计划，因此不会出现卡顿。

解决/排查方式：

• 在查询语句末尾添加OPTION (RECOMPILE)，强制每次执行重新生成计划：

  SELECT Date, Col1 FROM myTable
  WHERE Date = @myDate
  OPTION (RECOMPILE)
  

• 查看SQL Server执行计划缓存，对比不同参数下的计划差异。

2. 资源未正确释放或连接池耗尽 #

虽然代码使用了use关键字自动释放资源，但如果存在隐性泄漏（比如sw.Close()对应的Stopwatch未用use包裹），可能导致连接池可用连接不足，第三次执行需要等待新连接创建，引发卡顿。

解决/排查方式：

• 确保所有资源都用use包裹，比如Stopwatch：

  use sw = Stopwatch.StartNew()
  // 查询逻辑
  sw.Stop()
  

• 查看SQL Server的连接数统计，确认是否有大量未释放的连接。

3. 数据读取后的IO阻塞 #

第三次查询若返回数据量远大于前两次，Console.WriteLine的同步IO操作会成为瓶颈，看似查询卡顿，实际是数据处理阶段慢。SSMS的数据展示做了异步优化，不会出现这类问题。

解决/排查方式：

• 暂时注释Console.WriteLine代码，仅执行查询和读取操作，若不再卡顿则说明是输出环节的问题，可改为批量读取后再统一处理数据。

4. SQL Server统计信息过期或缓存失效 #

前两次执行后，数据缓存或执行计划被清理，第三次执行需要从磁盘重新读取数据，导致速度变慢。而SSMS会话的缓存未被清理，一直复用缓存数据。

解决/排查方式：

• 更新表统计信息：UPDATE STATISTICS myTable;
• 检查SQL Server缓存命中率，确认是否存在缓存失效情况。

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