必须组合SQL Server Agent、存储过程和PowerShell脚本才能实现自动化报告：Agent负责定时调度，存储过程执行检查并写入health_check_log表，PowerShell查询结果生成HTML并发送邮件。
不能靠单个存储过程“自动生成报告”——它不写文件、不发邮件、不存历史，只执行SQL。真要落地，必须组合SQL Server Agent + 存储过程 + 外部脚本（如PowerShell）三件套。
SQL Server Agent 是定时执行的唯一可靠入口
存储过程本身不会“每天自动跑”。你写好 sp_daily_health_check，不配 Agent 作业，它就永远躺在数据库里。Agent 是 SQL Server 唯一原生支持周期性调度的机制。
- 必须确认 Windows 服务
SQL Server Agent已启动，且运行账户对目标数据库有db_datareader和EXECUTE权限 - 作业步骤中“数据库”下拉框必须选对——不是你当前连接的库，而是存储过程所在的库（比如
master或专用DBAtools） - 命令栏直接写
EXEC sp_daily_health_check，别加USE [xxx]，否则上下文切换可能失败 - 计划时间填“每天 02:00”，注意服务器时区；若业务要求北京时间凌晨2点，就填
02:00，别自己换算 UTC
存储过程内部必须输出结构化结果并落库
巡检不是 SELECT 出来给人看，而是把指标固化成行。所有检查项都得插入一张日志表，比如 dbo.health_check_log，字段至少含：check_name、status（'OK'/'WARN'/'FAIL'）、value（数值或描述）、run_time。
- 磁盘空间检查：用
sys.dm_os_volume_stats查各驱动器剩余空间，free_space_mb 就标 <code>WARN，标 <code>FAIL - 阻塞会话：查
sys.dm_exec_requests中blocking_session_id > 0的记录数，大于 0 就记一条blocking_sessions日志 - 备份状态：查
msdb.dbo.backupset最近 24 小时内是否有type = 'D'，没有就记last_full_backup_missing - 每条 INSERT 后加
IF @@ERROR 0 BEGIN INSERT INTO health_check_log ... END，防某一项失败导致整批丢失
PowerShell 脚本才是生成 HTML 报告的关键环节
SQL Server 不提供原生 HTML 生成能力。真正“一键出报告”的动作，由外部 PowerShell 脚本完成：它连数据库查 health_check_log 最新一次的全部记录，拼成带样式的 HTML 文件，再发邮件或存共享目录。
- 脚本开头必须指定
$config.SqlServer = "YourInstanceName"和$config.ReportDir = "D:\reports\"，路径不存在要自动创建 - 查询语句用
SELECT * FROM health_check_log WHERE run_time >= DATEADD(hour, -25, GETDATE())，确保只取最新一轮（避免跨天错乱） - HTML 表格里，
status = 'FAIL'的行用红色背景，'WARN'用橙色，'OK'用绿色，视觉上立刻可判 - 不要在存储过程中尝试用
FOR XML拼 HTML——格式难控、编码易乱、无 CSS 支持，纯属给自己挖坑
最容易被忽略的三个细节
很多人卡在“报告生成了但没人收到”“历史数据查不到”“某天突然不跑了”，问题往往不在主逻辑，而在这些边缘点：
- Agent 作业失败时默认不告警，必须在作业属性 → 通知 → “当作业失败时”勾选“电子邮件”，并提前配置数据库邮件
-
health_check_log表没建索引，跑半年后SELECT TOP 100 ... ORDER BY run_time DESC变慢，建议在run_time上建非聚集索引 - PowerShell 脚本调用
Invoke-Sqlcmd时未加-QueryTimeout 300，遇到大表统计卡住，整个报告流程挂起
