主备切换后CPU异常升高，本质是切换暴露了环境不等价、同步积压、执行计划劣化、高频监控未限流或应用重试放大等问题；需验证角色与同步状态、排查会话级CPU热点、对比查询性能变化、检查系统态抖动及业务逻辑失当。

主备切换后 CPU 使用率异常升高，不是单纯“CPU变高了”这么简单，而是切换动作本身触发或暴露了底层资源、配置或业务逻辑的问题。重点不在切换是否成功，而在切换后环境是否等价、负载是否合理、同步是否干净。

确认切换是否真正完成且状态一致

主备切换后若 CPU 持续飙升，首先要排除“假主库”或“伪切换”——即实例已切换为角色主库，但实际未承接流量、或仍在追赶同步、或存在隐藏的后台任务。

• 查 SQL Server 角色状态：SELECT role_desc, operational_state_desc FROM sys.dm_hadr_availability_replica_states，确保当前节点 role_desc = 'PRIMARY' 且 operational_state_desc = 'ONLINE'
• 查同步延迟（Always On）：SELECT replica_server_name, synchronization_state_desc, log_send_queue_size, redo_queue_size FROM sys.dm_hadr_database_replica_states，若 redo_queue_size 持续增长，说明备库日志重做积压，主库可能因强制推送日志而额外消耗 CPU
• 检查是否有残留的 failover 脚本或监控探针在反复执行健康检查（比如每秒轮询 sys.dm_os_performance_counters），这类高频查询在新主库上未限流，极易推高 sy 时间

对比切换前后关键进程与会话行为

切换本质是服务迁移，CPU 异常往往源于“同一套业务逻辑在新环境跑出了不同开销”，比如执行计划变更、统计信息陈旧、连接池未重建等。

• 运行会话级 CPU 排序：SELECT session_id, cpu_time, logical_reads, reads, writes, status, login_name, program_name FROM sys.dm_exec_sessions s JOIN sys.dm_exec_requests r ON s.session_id = r.session_id WHERE r.status = 'running' ORDER BY r.cpu_time DESC，重点关注 program_name 是否含监控工具、ETL 调度器或 ORM 连接池标识
• 检查是否大量会话处于 suspended 状态但 wait_type 是 ASYNC_NETWORK_IO 或 LCK_M_* ——这说明应用未适配新主库的网络延迟或锁策略，导致连接堆积、线程空转争抢 CPU
• 对比切换前后 sys.dm_exec_query_stats 中 top 10 高 CPU 消耗语句的 execution_count 和 total_worker_time，若某条语句执行次数突增 5 倍以上，大概率是应用重连后未复用连接，反复编译/解析相同 SQL

排查平台层与系统级干扰项

公有云环境下，主备切换常伴随底层资源重调度（如虚拟机热迁移、网卡重绑定、存储路径切换），这些操作可能引发短暂但剧烈的系统调用抖动。

• 登录 OS 层，用 top -H 查看线程级占用，若 %sy（系统态）持续 >30%，说明内核忙于处理中断或上下文切换；再用 perf top -p $(pgrep -f "sqlservr") 看热点是否集中在 do_syscall_64 或 native_queued_spin_lock_slowpath，指向锁竞争或驱动问题
• 检查云平台控制台中的“实例监控”页，确认切换后是否触发了自动扩容、备份任务启动、或安全组规则批量刷新——这些后台任务常以 root 权限运行，且不体现在 SQL Server 的 DMV 中
• 验证时钟同步：切换后若新主库 NTP 同步异常，GETDATE() 类函数可能频繁触发内核时间校准，造成 sy 升高；可用 ntpq -p（Linux）或 w32tm /query /status（Windows）快速确认

验证业务逻辑是否隐式放大负载

很多场景下，CPU 异常不是数据库的问题，而是应用在切换后“行为失当”：比如重试机制未退避、缓存全失效、连接串未更新导致请求打到旧地址再被转发……最终在新主库上形成放大效应。

• 检查应用日志中是否出现密集的 “Connection refused” 或 “Login failed” 错误——说明部分请求仍发往原主库 IP，经负载均衡转发后增加新主库解析与认证压力
• 查看 SQL Server 错误日志中是否集中出现 “Timeout expired” 或 “Could not allocate space for object” ——可能是切换后 tempdb 未按预期重建，或查询突然走全表扫描（统计信息未自动更新）
• 临时启用查询 Store 捕获：ALTER DATABASE SCOPED CONFIGURATION SET QUERY_STORE = ON;，几小时后查 sys.query_store_runtime_stats，比对切换前后同语句的平均 CPU 时间变化，定位劣化最严重的查询