CPU飙到100%是SQL Server在干活，非Navicat线程失控；因还原操作强制单线程、密集解压校验写入，且MAXDOP无效，navicat.exe仅占3%~5%，sqlservr.exe占95%+。
Navicat还原时CPU飙到100%是线程失控还是SQL Server在干活？
不是navicat本身在狂占cpu，而是它调用的sql server还原过程正在密集解压、校验、写入——尤其当bak文件启用with compression且服务器只有2–4核时，单个restore database操作就能把cpu打满。此时任务管理器里看到sqlservr.exe占95%+，navicat.exe反而只有3%~5%，说明瓶颈在服务端，不是客户端gui。
为什么改“并发线程数”对Navicat无效？
Navicat GUI没有暴露还原线程控制开关，它的“高级选项”里所有设置（如超时、缓冲区大小）都不影响SQL Server内部并行度。真正决定CPU负载的是SQL Server自身的配置和还原命令参数：
-
MAXDOP还原时不生效——SQL Server还原操作强制单线程执行，无法通过OPTION (MAXDOP 1)限制 - 试图在Navicat里调低“连接数”或“查询超时”，对还原进度和CPU占用毫无影响
- 所谓“限制并发”只能落在SQL Server层面：要么停掉其他大作业腾出CPU，要么换时间窗口执行
必须改SQL Server配置才能降CPU压力吗？
不一定。更直接有效的做法是跳过Navicat GUI，用T-SQL手动控制行为：
- 加
WITH NORECOVERY+STATS = 5：减少日志刷盘频率，避免每页都触发检查点 - 确认BAK是否含多个备份集：
RESTORE HEADERONLY FROM DISK = 'x.bak'，漏写FILE = 2会导致SQL Server反复扫描头信息，CPU空转 - 若BAK来自高COMPRESSION级别（如SQL Server 2016+默认），还原时无法关闭解压，只能提前用
RESTORE VERIFYONLY确认有效性后，在业务低峰期执行 - 临时禁用
tempdb自动增长（设为固定大小）+ 把max server memory调高至物理内存的70%，能减少内存重分配引发的CPU抖动
低峰期执行要注意哪些隐藏陷阱？
很多人以为“凌晨2点跑还原就安全”，但忽略了三点：
- 云服务器可能在低峰期触发底层宿主机维护，导致I/O延迟突增，SQL Server被迫重试，CPU持续高位
- Windows自动更新服务（
wuauserv）常在凌晨3–4点静默启动，与还原争抢CPU，任务管理器里会看到两个svchost.exe进程交替冲到80%+ - Docker容器中运行SQL Server时，未设置
--cpus="2"限制，还原进程会吃光所有可用vCPU，连SSH都响应迟缓
真正稳妥的做法是：先用RESTORE VERIFYONLY验证BAK完整性，再选一个LOAD_PERCENTAGE低于30%的时间段（用sys.dm_os_performance_counters查历史负载），最后用sqlcmd非交互式执行，全程不依赖Navicat界面刷新逻辑。
