Azure SQL Serverless层数据库周期性超时问题的排查及优化建议

我们已从DTU迁移至Azure SQL Serverless层，当前配置如下：

• 层级：General Purpose Serverless
• 最小vCore：4
• 最大vCore：14
• 区域：West Europe
• 备份：本地冗余（已配置故障转移，未使用备份）

上述vCore范围为微软官方推荐值，配置整体运行稳定，但数据库频繁出现资源降级，导致API触发SQL超时，且系统需2-3分钟才能恢复正常。后台服务每30分钟运行一次，数据库全年24小时处于适中负载状态，无明显高负载情况。

此前存在SNAT端口耗尽问题，已通过在API应用服务与SQL资源间配置VNET解决；临时恢复措施为交换API槽以恢复连接。该问题近3周随机出现，无固定规律，目前正排查代码优化方向，寻求针对性排查点与可用性提升建议。

• Serverless自动缩放触发逻辑：检查是否存在短时间负载尖峰/特定查询导致的负载波动触发向下缩放，或缩放阈值与实际负载不匹配
• 长时间运行查询：排查后台服务或API的查询是否存在执行超时、锁等待、阻塞等情况，这类操作可能干扰资源缩放判断
• 资源使用趋势：分析CPU、内存、IOPS等指标在降级前的变化，确认是否存在周期性资源占用低谷触发自动降级
• 故障转移机制：验证故障转移是否偶发触发，导致资源重新分配时出现临时降级
• 连接池配置：检查API的数据库连接池是否存在连接泄漏，异常连接占用可能间接影响资源缩放逻辑

• 查看Azure SQL自动缩放日志：在Azure门户的SQL数据库资源中，找到「自动缩放」相关日志，查看每次降级的触发条件（如CPU持续低于阈值的时长、内存使用率等）
• 分析查询存储（Query Store）：捕获降级前后的查询执行数据，识别是否有异常查询占用资源或引发负载波动
• 启用扩展事件（Extended Events）：跟踪资源缩放相关事件，记录降级发生时的系统状态、查询活动等细节
• 监控核心资源指标：重点关注CPU使用率、内存使用率、连接数、IO延迟等指标在降级前后的变化趋势，确认是否达到自动缩放触发阈值
• 检查后台服务执行日志：确认降级发生时段是否有后台服务执行，其查询是否对数据库资源产生了异常影响

• 调整Serverless缩放参数：适当提高最小vCore值，或延长自动降级的等待时长（默认5分钟），避免短暂负载低谷触发不必要的降级
• 优化查询性能：通过Query Store定位慢查询，进行索引优化、查询改写，降低资源占用
• 调整后台服务调度：错开多个后台任务的执行时间，避免并发触发导致的资源波动；或对后台任务进行资源隔离
• 启用只读副本：将非实时查询（如报表、数据分析）分流到只读副本，减轻主库负载
• 设置监控告警：针对资源缩放、CPU使用率、连接数等指标配置告警，及时捕获降级前兆并介入处理
• 优化连接管理：确保API连接池配置合理，避免连接泄漏，减少不必要的数据库连接占用

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