sp_updatestats 不能当健康检查用，因为它只更新统计信息、无返回状态、不检测异常、静默执行且跳过失败对象；真正健康检查需用 spwho2、sys.dm* 视图或自定义存储过程。
sp_updatestats 是 SQL Server 系统存储过程，**不用于健康检查，而是用于更新统计信息**。把它当健康检查手段用，属于典型误用——它既不返回状态、不检测异常、也不提供诊断输出，执行完就静默结束。真要靠它“检查健康”，等于拿锤子当温度计用。
为什么 sp_updatestats 不能当健康检查用
这个过程只做一件事：遍历当前数据库所有用户表和索引视图，对尚未更新过统计信息或行数变化超过阈值的列，调用 UPDATE STATISTICS。它没有返回值（RETURN 值恒为 0），不记录失败对象，也不校验统计质量。即使某张表因权限不足、页损坏或锁冲突跳过更新，它也照样返回成功。
SQL Server 中真正能用于健康检查的系统存储过程
健康检查需要可观测、可判断、可告警。以下才是实际可用的系统过程：
-
sp_who2：快速查看阻塞链、长时间运行会话、资源占用异常的spid；注意它已标记为“向后兼容”，生产环境建议改用sys.dm_exec_requests+sys.dm_exec_sessions查询 -
sp_lock：显示当前锁信息（但输出格式老旧，且不包含等待时间）；更推荐sys.dm_tran_locks配合sys.dm_os_waiting_tasks -
sp_blitz（非系统内置，但广泛部署）：由 Brent Ozar 团队开发的免费诊断脚本，一次调用即可输出 CPU 过载、备份缺失、自动增长异常、碎片率超标等 100+ 项问题，并分级标注严重性
如何用存储过程真正实现健康检查逻辑
必须自己写——把检查动作封装成带输出参数或结果集的自定义存储过程。例如检查长事务：
CREATE PROCEDURE dbo.usp_CheckLongRunningTransactions
AS
BEGIN
SET NOCOUNT ON;
SELECT
session_id,
wait_time,
wait_type,
DATEDIFF(minute, transaction_begin_time, GETDATE()) AS duration_min
FROM sys.dm_tran_active_transactions t
JOIN sys.dm_tran_session_transactions st ON t.transaction_id = st.transaction_id
JOIN sys.dm_exec_sessions s ON st.session_id = s.session_id
WHERE DATEDIFF(minute, transaction_begin_time, GETDATE()) > 10;
END;
关键点：
- 明确返回结果集或
@output_msg NVARCHAR(500)输出提示 - 在调用方（如 Agent Job 或监控脚本）中捕获结果行数：
IF @@ROWCOUNT > 0 RAISERROR('发现长事务', 16, 1) - 避免依赖
PRINT——它不会被作业日志或告警系统捕获
容易踩的坑
直接拿系统过程当健康检查入口，最常掉进三个坑：
- 误把
sp_updatestats执行成功当成“统计信息健康”——其实可能全表都跳过了，因为READ_COMMITTED_SNAPSHOT开启时部分元数据不可见 - 用
sp_who2解析文本输出做自动化判断——字段无固定列宽，版本升级后列顺序可能变，解析极易断裂 - 在健康检查存储过程中使用
WAITFOR DELAY或大范围游标——拖慢巡检本身，还可能干扰业务
真正可靠的健康检查，永远建立在可量化指标（如 sys.dm_os_performance_counters 中的 Page life expectancy）、明确阈值（如 log_reuse_wait_desc != 'NOTHING'）、以及结构化输出基础上。系统过程只是工具，不是答案。
