连接相同Azure SQL数据库时App Service查询超时但本地正常如何排查

排查与解决措施 #

1. 确认执行计划差异（参数嗅探验证） #

同参数、同库但不同端执行效率差异，最常见的原因是不同客户端的SET配置不同导致生成了多份执行计划缓存：

• .NET应用默认ARITHABORT为OFF，而SSMS/本地调试时默认ARITHABORT为ON，即使参数完全相同，SQL Server也会视为不同的查询生成独立的执行计划，你执行DBCC FREEPROCCACHE后如果是App Service侧先触发查询，很可能用倾斜参数生成了低效执行计划。
• 验证方法：将EF Core生成的完整SQL语句取出，在SSMS中先执行以下语句模拟.NET客户端配置，再运行查询看是否复现超时：

SET ARITHABORT OFF;
SET ANSI_NULLS ON;
SET ANSI_PADDING ON;
SET ANSI_WARNINGS ON;
SET CONCAT_NULL_YIELDS_NULL ON;
SET NUMERIC_ROUNDABORT OFF;
SET QUOTED_IDENTIFIER ON;
-- 替换为你的实际查询SQL

如果该模式下执行也超时，即可确认是执行计划/参数嗅探问题。

2. 参数嗅探修复方案 #

• 查询级重编译：针对该慢查询，通过EF Core的TagWith附加重编译提示，强制每次执行生成最优执行计划：

var queryResult = dbContext.YourTable
    .Where(/*你的查询条件*/)
    .TagWith("OPTION (RECOMPILE)")
    .ToList();

也可以通过EF Core命令拦截器，自动给指定SQL添加OPTION (RECOMPILE)查询提示。

• 参数类型匹配优化：查看日志中两个字符串参数@__key_TransportationType_4、@__key_CostCenter_5对应的数据库字段类型：
  • 如果数据库字段是varchar而非nvarchar，需要在EF模型配置中添加IsUnicode(false)，避免隐式编码转换导致索引失效
  • 显式指定字段长度与数据库一致（比如HasMaxLength(50)），避免EF默认生成4000长度的参数导致索引无法匹配
• 绑定优质执行计划：Azure SQL默认开启查询存储（Query Store），进入Azure SQL门户的查询存储面板，找到该慢查询，直接绑定本地执行时的高效执行计划即可，无需修改代码。

3. 非参数嗅探场景排查 #

• 网络与部署配置检查：确认App Service与Azure SQL部署在同一Azure区域，跨区域访问会带来额外网络延迟，大量数据返回时会放大耗时；可进入App Service的Kudu控制台，使用tcpping <你的SQL地址>:1433测试网络延迟，同区域正常延迟应低于10ms。
• App Service资源检查：查看App Service Plan的监控指标，确认执行查询时段CPU、内存、出站连接数没有达到瓶颈，避免因宿主资源不足导致查询处理慢。
• EF配置一致性检查：确认线上与本地使用的EF Core版本完全一致，避免版本差异导致生成的SQL语句逻辑不同；针对只读查询添加AsNoTracking()关闭实体跟踪，降低大结果集的内存开销。

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