Azure SQL DB P4升级后无法正常扩容，仍遇连接断开及性能下降问题

一、获取当前并发工作线程数的方法 #

• 实时SQL查询
  执行以下查询获取当前工作线程的分布与总数：

  SELECT 
      COUNT(*) AS 当前工作线程数,
      scheduler_id AS 调度器ID
  FROM sys.dm_os_workers
  WHERE is_preemptive = 0
  GROUP BY scheduler_id;
  

  若要关联到具体会话，可使用：

  SELECT 
      c.session_id AS 会话ID,
      c.connect_time AS 连接时间,
      w.state AS 线程状态
  FROM sys.dm_exec_connections c
  JOIN sys.dm_os_workers w ON c.session_id = w.session_id
  WHERE c.session_id > 50; -- 过滤系统会话
  

• Azure门户监控
  在数据库的「监控」面板中，添加「工作线程百分比」指标，可直观查看线程使用率的实时趋势，对比P4的800线程上限判断是否触达阈值。

二、其他关键检查方式 #

• 排查连接断开原因
  查询系统日志获取连接失败/断开的具体信息：

  SELECT 
      event_time AS 事件时间,
      error_number AS 错误码,
      error_message AS 错误信息,
      session_id AS 会话ID
  FROM sys.event_log
  WHERE event_type IN ('connection_failed', 'connection_closed')
  ORDER BY event_time DESC;
  

• 分析阻塞与等待事件
  检查当前阻塞情况：

  SELECT 
      blocking_session_id AS 阻塞会话ID,
      session_id AS 会话ID,
      wait_type AS 等待类型,
      wait_time_ms AS 等待时长(毫秒)
  FROM sys.dm_exec_requests
  WHERE blocking_session_id <> 0;
  

  重点关注等待类型：如PAGEIOLATCH_*代表IO瓶颈，LCK_M_*代表锁阻塞，这些均会导致性能下降与连接异常。
• 细分资源消耗检查
  即使整体DTU使用率仅40-45%，可能存在单项资源瓶颈（如CPU、数据IO、日志写入）。在Azure门户的「DTU明细」面板查看各分项的占比，确认是否有单项达到上限。
• 应用层连接池配置核查
  确认应用连接池的最大连接数设置是否合理，是否存在连接泄漏导致无效连接占用数据库资源。

三、并发线程是否为核心原因的判断 #

如果排查发现工作线程数持续接近或达到800上限，那么并发线程耗尽就是连接断开与性能下降的主要原因——此时新请求无法分配到工作线程，会触发超时或断开。
若线程数远低于上限，则需聚焦其他因素：比如IO资源饱和、锁阻塞、未优化的慢查询占用资源、临时数据库压力过大等。

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