Azure S1 App Service Plan连接SQL数据库偶发命令执行缓慢如何排查

第一步：从Azure SQL侧抓取明确的等待信息与阻塞链 #

传统SQL Profiler无法适配Azure SQL的运行机制，采集信息不全且会额外占用数据库性能，优先使用Azure内置工具与系统视图排查：

• 登录Azure门户进入对应SQL数据库的查询性能洞察面板，开启等待统计收集，可直接展示所有等待类型的占比，快速区分是IO等待、锁等待、资源配额不足还是网络类等待。
• 执行以下系统视图查询，直接抓取实时阻塞链信息：

WITH BlockingChain AS (
    SELECT 
        session_id, blocking_session_id, command, 
        wait_type, wait_time, text AS executed_sql
    FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
    WHERE blocking_session_id <> 0
    UNION ALL
    SELECT 
        r.session_id, r.blocking_session_id, r.command, 
        r.wait_type, r.wait_time, t.text AS executed_sql
    FROM sys.dm_exec_requests r
    CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
    INNER JOIN BlockingChain bc ON r.session_id = bc.blocking_session_id
)
SELECT * FROM BlockingChain ORDER BY blocking_session_id;

查询结果会直接输出阻塞源头会话的执行SQL、等待类型、已等待时长，可直接定位具体等待对象。

第二步：排查EF Core侧常见触发原因 #

• 检查数据库上下文释放逻辑：确认所有EF Core上下文都用using语句包裹，或已配置依赖注入自动释放，上下文泄露会导致连接池被占满，新的数据库请求会直接进入排队等待状态，该场景通常伴随偶发的连接超时报错。
• 校验慢查询索引合理性：开启EF Core日志输出完整的执行SQL，拿到SQL数据库侧生成执行计划，确认是否存在未命中索引的全表扫描/全索引扫描，并发场景下这类慢查询会产生大量行锁甚至表锁，导致后续查询进入锁等待。
• 核对连接池配置：确认连接字符串中Max Pool Size参数配置合理，默认值为100，S1层App Service的并发请求如果超过连接池上限，也会导致新的数据库请求排队等待。

第三步：低频率偶发场景的排查方案 #

如果问题出现频率极低无法实时捕获，可开启Azure SQL的自动优化功能，该功能会自动记录所有慢查询、等待统计与对应的索引优化建议，不需要人工实时盯守，待问题再次出现后即可回溯完整上下文。

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