ASP.NET Core 3.1调用Azure SQL存储过程偶发超时问题求助

代码层面问题排查与优化 #

1. 冗余的连接关闭操作 #

代码中手动调用connection.Close()完全多余，SqlConnection被包裹在using块中，会自动释放连接到连接池，手动关闭可能干扰连接池的正常管理，建议直接删除该行。

2. 同步操作导致线程池阻塞 #

在ASP.NET Core高并发场景下，同步的Fill()方法会阻塞线程池线程，当并发量上升时，容易引发线程池耗尽，间接导致超时。建议替换为异步版本：

public async Task<DataTable> GetData(long param1, long param2, long param3, long param4)
{
    DataTable result = new DataTable();
    using (var connection = new SqlConnection(_objDBContext.Database.GetDbConnection().ConnectionString))
    {
        await connection.OpenAsync();
        using (SqlCommand command = new SqlCommand("[TT].[GetData]", connection))
        {
            command.CommandType = CommandType.StoredProcedure;
            command.Parameters.Add(new SqlParameter("@Param1Id", SqlDbType.BigInt) { Value = param1 });
            command.Parameters.Add(new SqlParameter("@Param2", SqlDbType.BigInt) { Value = param2 });
            command.Parameters.Add(new SqlParameter("@Param3", SqlDbType.BigInt) 
            { 
                Value = param3 == 0 ? DBNull.Value : (object)param3 
            });
            command.Parameters.Add(new SqlParameter("@Param4", SqlDbType.BigInt) { Value = param4 });
            
            using (var sda = new SqlDataAdapter(command))
            {
                DataSet ds = new DataSet();
                await sda.FillAsync(ds);
                if (ds.Tables.Count > 0)
                {
                    result = ds.Tables[0];
                }
            }
        }
    }
    return result;
}

3. 数据返回类型优化 #

返回dynamic类型的DataTable存在序列化效率低、类型不安全的问题，建议将结果映射为强类型DTO列表，减少序列化开销，同时提升代码可维护性。

数据库端排查与优化 #

1. 存储过程参数嗅探问题 #

偶发超时大概率与参数嗅探有关：当存储过程第一次执行时生成的执行计划，可能不适合后续某些参数组合（比如@Param3为0和非0的场景）。可以通过以下方式解决：

• 在存储过程中使用局部变量接收参数，避免直接使用传入参数：

  CREATE PROCEDURE [TT].[GetData]
      @Param1Id BIGINT,
      @Param2 BIGINT,
      @Param3 BIGINT,
      @Param4 BIGINT
  AS
  BEGIN
      DECLARE @LocalParam1 BIGINT = @Param1Id;
      DECLARE @LocalParam2 BIGINT = @Param2;
      DECLARE @LocalParam3 BIGINT = @Param3;
      DECLARE @LocalParam4 BIGINT = @Param4;
      
      -- 原查询逻辑，使用局部变量
      SELECT ... FROM ... WHERE ...
  END
  

• 或者在查询末尾添加OPTION (RECOMPILE)，强制每次执行重新生成执行计划（适合参数差异大的场景）。

2. 检查执行计划与索引 #

执行以下语句查看存储过程的执行计划，排查是否存在表扫描、缺失索引等问题：

SET SHOWPLAN_XML ON;
EXEC [TT].[GetData] @Param1Id=xxx, @Param2=xxx, @Param3=xxx, @Param4=xxx;

根据执行计划添加对应的非聚集索引，减少数据扫描范围。

3. Azure SQL弹性池性能监控 #

在Azure Portal查看弹性池的以下指标：

• CPU/DTU使用率：是否出现峰值接近100%的情况，若有需调整弹性池规格或拆分负载
• 数据IO/日志写入百分比：排查是否存在IO瓶颈
• 等待统计：执行SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;，重点关注PAGEIOLATCH_*（IO等待）、LCK_M_*（锁等待）、CXPACKET（并行等待）等类型，针对性优化。

4. 连接池与连接字符串优化 #

• 调整连接字符串的Max Pool Size（默认100）：若并发量高，可适当调高，但不超过Azure SQL的连接限制
• 调整Connection Timeout（默认15秒）：可临时调整为30秒，避免因短时间网络波动导致超时
• 建议使用Microsoft.Data.SqlClient替换旧的System.Data.SqlClient驱动，该驱动针对Azure SQL做了更多优化。

其他建议 #

• 添加详细日志：记录每次调用的参数、执行时间，以及超时发生时的上下文信息，帮助定位特定参数组合引发的问题
• 实现幂等重试：使用Polly等库针对超时错误添加重试策略，注意确保存储过程是幂等的，避免重复执行导致数据异常
• 升级.NET版本：ASP.NET Core 3.1已停止支持，建议升级到.NET 6+，获得更好的性能、稳定性以及最新的数据库驱动支持

内容的提问来源于stack exchange，提问作者santosh kumar patro