SSRS报告并行执行查询性能异常骤降，求排查方向

这种并行查询时资源抢占导致的性能劣化确实挺棘手的，我之前处理过类似的问题，给你几个具体的排查方向，你可以逐一验证：

数据库层面：深挖资源竞争与执行细节 #

• 锁定与阻塞的深度分析：活动监视器有时候不够细致，建议用sp_who2快速排查会话阻塞关系，或者查询sys.dm_tran_locks、sys.dm_os_wait_stats看具体的等待类型。比如并行执行同个查询时，会不会出现共享锁的争抢？或者某个查询触发了锁升级，导致另一个查询长时间等待？重点关注PAGEIOLATCH_*（I/O等待）、LCK_M_*（锁等待）这类指标，它们能直接反映资源冲突点。
• 执行计划的一致性检查：两次并行执行同个查询，会不会因为参数嗅探、缓存失效生成了不同的执行计划？你可以用sys.dm_exec_cached_plans结合sys.dm_exec_query_stats，对比两次查询的执行计划哈希值，看看是否一致。如果存在重编译，查一下sys.dm_exec_query_optimizer_info里的重编译原因（比如sql_statistics、object_stats），这可能是导致性能波动的关键。
• I/O子系统压力验证：你提到资源释放缓慢，很大概率是磁盘I/O扛不住并行读请求。可以查询sys.dm_os_performance_counters里的磁盘计数器，比如PhysicalDisk: % Disk Time（是否接近100%）、PhysicalDisk: Avg. Disk Sec/Read（是否超过20ms的阈值）。如果是SAN存储，还要联系运维确认存储端有没有队列积压、带宽限制或者故障。

SSRS与查询逻辑层面：排查执行机制与代码问题 #

• 数据集会话与临时库压力：检查这个慢查询的逻辑，有没有依赖会话级设置（比如SET ARITHABORT、SET ANSI_NULLS）？SSRS并行执行时，每个数据集的会话设置可能不一致，导致执行计划变差。另外，查询里如果用到大临时表/表变量，并行执行时会给tempdb带来巨大压力——确认下tempdb的文件配置是否合理（多个等大的数据文件、自动增长步长合适），避免tempdb成为瓶颈。
• SSRS执行日志分析：利用SSRS的ExecutionLog3视图，对比并行和串行执行时每个数据集的开始/结束时间、CPU/内存占用。你能从日志里看到并行时是不是某个数据集的启动时间被延迟，或者资源占用异常。另外，确认下SSRS的Maximum Concurrent Connections配置，不过你是并行5个查询，这个大概率不是问题，但排查下更稳妥。
• 查询并行度的限制测试：试试给这个查询加OPTION (MAXDOP 1)强制串行执行，然后对比单次、并行两次的耗时变化。如果并行时的耗时明显下降，说明原查询的并行度设置太高（比如数据库默认MAXDOP过大），导致单个查询就占满了CPU/内存，两个一起跑就互相抢占资源。

服务器硬件与系统层面：排查资源瓶颈与释放延迟 #

• CPU与内存资源监控：并行执行时，用任务管理器或性能监视器看CPU每个核心的使用率（是不是全满）、内存的Available MBytes（是不是不足）、Page Faults/sec（是不是频繁换页）。如果CPU瓶颈，可能是查询的并行扫描占满了核心；如果内存不足，缓存的页面被频繁换出，后续查询不得不重新读磁盘，导致耗时飙升。
• 系统资源释放延迟排查：你提到一个查询完成后另一个剩余耗时更长，可能是操作系统层面的线程、内存页释放不及时。可以用sys.dm_os_threads查看SQL Server的线程数变化，或者用Process Explorer观察SQL Server进程的内存/线程回收情况，排查是否存在内存泄漏或线程堆积的问题。

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