将应用从VPS迁移至Azure App Service后Azure SQL DB性能骤降原因排查

这种迁移后出现的SQL性能退化在Azure环境里挺常见的，我之前帮客户排查过类似的问题，分享几个实用的方向：

1. 先排查Azure SQL DB的资源瓶颈 #

首先打开Azure Portal，查看SQL DB的核心指标：

• CPU/DTU使用率：如果高峰时段接近100%，说明资源不够，考虑升级服务层（比如从S0升到S3）或者调整弹性池配置
• 等待统计：重点看LOG_RATE_GOVERNOR（日志写入速率限制）、PAGEIOLATCH_*（IO等待）、LCK_M_*（锁等待）这些类型，它们直接指向性能瓶颈的根源
• 连接数：如果连接数接近SQL DB的上限，会导致新请求排队超时，检查App Service的连接池设置（比如Max Pool Size），避免不必要的长连接

2. 对比查询执行计划的变化 #

即使是相同的查询，迁移后环境变化可能让查询优化器选择了低效的执行计划：

• 用Query Store找到那些超时的查询，对比迁移前后的执行计划，看是否出现了索引失效、全表扫描或者参数嗅探的问题
• 先尝试更新统计信息，让优化器拿到最新的数据分布：

  UPDATE STATISTICS [你的表名] WITH FULLSCAN;
  

• 如果是参数嗅探导致的，可以临时用OPTION (RECOMPILE)来生成适配当前参数的计划，或者创建计划指南固化高效的执行计划

3. 检查网络层面的延迟问题 #

App Service和SQL DB的网络连接是容易被忽略的点：

• 确认两者是否在同一Azure区域，跨区域的网络延迟会大幅增加查询的往返时间，即使查询本身很快也会触发超时
• 如果必须跨区域，配置VNet集成或者专用端点，避免走公网流量
• 在App Service的Kudu控制台里用tcpping命令测试到SQL DB的延迟：

  tcpping your-sql-server.database.windows.net 1433
  

  正常延迟应该在几十毫秒以内，如果超过100ms就需要优化网络配置

4. 验证应用的连接与重试逻辑 #

迁移后应用的连接配置可能需要调整：

• 检查连接字符串的Command Timeout设置，是否因为Azure环境的网络波动需要适当调大（比如从30秒调到60秒），但不要盲目调大，还是要从根源解决
• 检查应用的重试机制，如果没有做指数退避，频繁重试会加剧SQL DB的负载，导致更多超时。建议用重试库实现智能重试，只对连接超时这类可重试的错误进行操作

5. 排查TempDB的性能问题 #

如果查询用到了临时表或表变量，TempDB的配置可能成为瓶颈：

• 检查TempDB的等待统计，比如PAGEIOLATCH_SH这类等待，说明TempDB的IO性能不足
• 调整TempDB的数据文件数量（建议和SQL DB的CPU核心数一致），并且设置相同的初始大小和增长速率，避免自动增长导致的碎片

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