在C#中监控数据库的等待统计并识别瓶颈，通常需要结合数据库端的性能视图（如SQL Server的
sys.dm_os_wait_stats）和应用程序端的数据采集与分析。直接通过C#代码无法“主动”获取这些信息，但可以通过执行查询、定期轮询、记录日志等方式实现监控。
1. 查询SQL Server等待统计信息
SQL Server提供动态管理视图（DMV）来查看系统级别的等待情况。你可以通过C#执行T-SQL查询来获取这些数据：
SELECT wait_type, waiting_tasks_count, wait_time_ms, max_wait_time_ms, signal_wait_time_ms FROM sys.dm_os_wait_stats WHERE wait_time_ms > 0 ORDER BY wait_time_ms DESC常见的高耗时等待类型包括：
ASYNC_NETWORK_IO：可能是应用读取结果慢，网络或客户端处理问题 LCK_M_XX：锁等待，存在阻塞 PAGEIOLATCH_XX：磁盘I/O压力大 WRITELOG：事务日志写入慢 CXPACKET：并行查询等待，可能涉及并行度设置不合理在C#中使用
SqlConnection和
SqlCommand定期执行该查询，并将结果记录到日志或监控系统中。
2. 在C#中实现定时采集
可以使用
Timer或后台服务（如
IHostedService）定期采集等待统计： var timer = new Timer(async _ => { using var conn = new SqlConnection(connectionString); await conn.OpenAsync(); using var cmd = new SqlCommand(@" SELECT wait_type, wait_time_ms, signal_wait_time_ms FROM sys.dm_os_wait_stats WHERE wait_time_ms > 500 ORDER BY wait_time_ms DESC", conn); using var reader = await cmd.ExecuteReaderAsync(); while (await reader.ReadAsync()) { Console.WriteLine($"{reader["wait_type"]}: {reader["wait_time_ms"]}ms"); } }, null, TimeSpan.Zero, TimeSpan.FromMinutes(5));
建议将采集频率控制在合理范围（如每5分钟一次），避免频繁查询影响性能。
3. 对比前后快照识别变化
单次查询只能看到累计值，要识别“当前瓶颈”，应做差值快照：
第一次采集所有等待类型的wait_time_ms等待一段时间（如1分钟）后再次采集 计算两次之间的差值，关注增长最快的等待类型
这种“增量分析”能更准确反映当前系统的实际等待瓶颈。
4. 结合执行计划和会话监控定位问题
等待统计只是线索，还需进一步定位具体SQL或会话：
查询当前活动请求：sys.dm_exec_requests查看
wait_type和
command查看阻塞链：
sys.dm_exec_requests中的
blocking_session_id获取SQL文本：
sys.dm_exec_sql_text(sql_handle)分析执行计划：
sys.dm_exec_query_plan(plan_handle)
C#中可封装这些查询，当发现异常等待时自动抓取上下文信息。
5. 集成日志与告警
将采集到的等待数据写入日志系统（如Serilog、NLog）或发送到监控平台（Prometheus、ELK）：
设定阈值（如某类等待超过10秒/分钟）触发告警 记录时间戳、等待类型、持续时间等结构化字段 结合应用性能指标（响应时间、吞吐量）综合分析基本上就这些。关键是把数据库的等待统计当作“症状”，用C#做数据采集器，再结合DBA工具深入分析根因。不复杂但容易忽略的是做差值快照——否则看到的只是历史累计，不是实时瓶颈。
