.NET Core WebApi并行调用SQL Server存储过程耗时大幅变长问题

观测到的现象并非WebApi端并行失效导致的串行排队，本质是数据库端的并行资源争用+后端连接管理逻辑冗余叠加的结果，不属于无法避免的固定开销，理论上完全可以实现整体耗时与单个慢请求持平（6-8秒级）。

已排除的无效怀疑方向 #

从SQL Server Profile观测到6个RPC:Starting事件同时触发，说明请求已经顺利从WebApi送达数据库，不存在WebApi管道、Angular端、TCP连接层面的串行排队问题，代码层面的异步并行逻辑是生效的，不需要怀疑前端或者API层的并行实现。

后端代码的冗余问题 #

当前数据库调用的实现存在两处不必要的开销：

• CollectionFromSp扩展方法完全绕过了EF Core内置的连接生命周期管理：直接基于连接字符串新建独立的SqlConnection实例，不使用DbContext已经从连接池获取的活动连接，每个请求都会额外触发一次连接池的连接分配流程。
• 上层业务方法中手动调用CTBdc.Database.CloseConnection()的逻辑完全冗余：会强制断开DbContext持有的连接，如果同一请求链路后续还有其他数据库操作，会触发额外的连接重开开销。
  该逻辑虽然不会直接导致串行执行，但会额外消耗连接池配额，在高并发场景下可能触发连接等待。

数据库端的核心争用（导致耗时翻6倍的主因） #

6个请求同时到达数据库后，因为查询本身的资源占用特征，会出现资源抢占式的准串行执行：

• 单请求单独测试时6-8秒的耗时，往往是因为测试时数据库缓冲池已经缓存了查询需要的全部页，且系统会把全部可用IO、CPU资源分配给单个查询，没有竞争开销。
• 6个请求并行发起时，如果查询本身需要扫描大量数据（无匹配索引），会瞬间打满服务器的磁盘IO带宽，所有请求的读操作都要排队等待磁盘响应；如果SQL Server默认将所有CPU核分配给单个查询（MAXDOP=0的默认配置），6个大查询同时发起时会瞬间占满CPU，触发大量上下文切换，进一步拉低执行效率；如果查询默认的隔离级别没有调整，扫描大表时加的共享锁、缓冲区闩锁也会造成请求间的相互阻塞，哪怕是纯读操作，也会把并行请求卡成准串行。

1. 修正后端连接管理逻辑 #

• 移除CollectionFromSp中手动新建SqlConnection的逻辑，直接使用dbContext.Database.GetDbConnection()获取连接池中的活动连接，复用DbContext的连接管理流程，减少不必要的连接分配开销。
• 移除业务方法中手动调用CloseConnection()的代码，让EF Core根据请求生命周期自动释放连接，不要手动干预连接状态。

2. 数据库端排查与调整 #

• 当6个请求并行执行时，通过sys.dm_os_waiting_tasks系统视图查看所有请求的等待类型，针对性调整：
  • 如果等待项为PAGEIOLATCH_*，说明是磁盘IO争用，需要给存储过程的查询字段添加覆盖索引，把单查询的逻辑读量降一个数量级（比如从百万级行读降到十万级以内），减少IO占用。
  • 如果等待项为SOS_SCHEDULER_YIELD，说明CPU被占满，需要把SQL Server实例的MAXDOP配置调整为2-4（适配报表类大查询的资源分配），避免单个查询占满所有CPU核，保证多个并行请求都能拿到足够的CPU时间片。
  • 如果等待项为LCK_M_*，说明是锁争用，对于纯只读的报表查询，可将存储过程的隔离级别调整为READ UNCOMMITTED或启用快照隔离，缩小锁的范围和持有时间。
• 单独验证每个存储过程在冷缓存、无并发场景下的真实查询耗时，确认是否存在参数嗅探导致的低效执行计划，必要时为存储过程固定适配的执行计划。

完成上述调整后，6个并行请求的整体完成时间基本会和最慢的单个存储过程耗时持平（6-8秒级），不会出现线性放大的延迟。

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