用途：判断 Azure SQL Database 变慢的根因是 CPU、数据 IO、日志 IO、内存，还是工作线程（worker）与会话（session）上限。核心思路是问“撞到了哪个受治理的上限”，而不是看机器有多忙；每个上限的修复方式不同，只有部分能靠扩缩容解决。
主要能力：先用 SERVERPROPERTY('EngineEdition')、Edition 与 sys.dm_db_resource_stats 的 dtu_limit、cpu_limit 判断购买模型（DTU 或 vCore）与运行环境。CPU 看 avg_cpu_percent 与 avg_instance_cpu_percent（两者尺度不同、不可直接比较，任一进入 70–100 会压平吞吐）；DTU 库的总体指标为 avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)。IO 用 sys.dm_io_virtual_file_stats 的 io_stall_queued_read_ms/io_stall_queued_write_ms 区分 IO 治理延迟与存储延迟；日志速率治理表现为 LOG_RATE_GOVERNOR、POOL_LOG_RATE_GOVERNOR、INSTANCE_LOG_RATE_GOVERNOR 等待。内存看 sys.dm_os_memory_clerks 与 sys.dm_exec_query_resource_semaphores（waiter_count 大于 0 且 available_memory_kb 接近 0 表示内存授予排队）；avg_memory_usage_percent 接近 100 不是故障。工作线程与会话看 max_worker_percent、max_session_percent，错误 10928/10929/10936 需先读 Resource ID（1 为 workers，2 为 sessions）。
使用方式：按步骤执行文中给出的 T-SQL 查询；诊断连接可用 sqlcmd 加 -A（或服务器名前缀 admin:），需逻辑服务器管理员，不支持 -G，每库仅一个。MAXDOP 用 sys.database_scoped_configurations 查看，用 ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 8; 修改，需 server admin、db_owner 或 ALTER ANY DATABASE SCOPED CONFIGURATION，且不能对 master 执行。
适用场景与限制：适用于 Azure SQL Database；本地容器中 sys.dm_db_resource_stats、sys.resource_stats 等返回 Msg 208，需改用计划缓存与文件统计查询。sys.dm_os_performance_counters 权限因层级而异。扩缩容只提升 CPU、内存、IO 余量与 worker/session 上限，不修复低效查询，也不改变 MAXDOP。资源统计每 15 秒一行、回溯约一小时；更早事件用逻辑服务器 master 中的 sys.resource_stats（5 分钟粒度、14 天）。