SQL存储过程本身不适合做自动化巡检的主干逻辑，只能封装检查动作；真正的自动化必须依赖外部调度器（如SQL Server Agent、cron、pg_cron、Airflow）来调用、判阈值、发告警。
巡检脚本该用存储过程还是外部调度
直接说结论：SQL 存储过程本身不适合做「自动化巡检」的主干逻辑，它只能承担「检查动作的封装」，真正的自动化必须依赖外部调度器（如 SQL Server Agent、cron、pg_cron、Airflow）。存储过程没有内置定时能力，也不能可靠发邮件、写日志文件或触发告警——这些都得靠调用它的宿主环境完成。
所以实际做法是：把每个巡检项（比如表空间使用率、阻塞会话、索引碎片）写成独立的存储过程或内联表值函数，再由调度器按需调用、捕获返回结果、判断阈值、执行通知。
-
sp_spaceused这类系统存储过程可直接复用，但注意它在 SQL Server 中不支持参数化数据库名，需用EXEC动态拼接 - PostgreSQL 中应优先用
pg_stat_database、pg_tablespace等视图，避免依赖pgstattuple扩展（需额外安装且扫描开销大） - MySQL 里
INFORMATION_SCHEMA查询性能差，高频巡检建议改用performance_schema或定期缓存到本地表
怎么让巡检结果可判断、可告警
关键不是“查出来”，而是“能自动判别是否异常”。不要只 SELECT 一堆数字，要统一输出结构化的检查结果集，每行代表一个检查项的状态。
推荐返回三列：check_name（如 'tempdb_usage_pct'）、status（'OK' / 'WARN' / 'CRITICAL'）、detail（具体数值+单位，如 '89.2%' 或 '12 blocking sessions'）。
- SQL Server 示例：用
IF @usage_pct > 90 BEGIN INSERT INTO #alerts ... END而不是直接PRINT - 避免在过程中用
RAISERROR模拟告警——这会中断事务，且无法被调度器稳定捕获；改用临时表或全局临时表暂存结果 - MySQL 存储过程不支持 RETURN 值，必须用
OUT参数或写入日志表，否则调用方无法获取状态
哪些巡检项适合放进存储过程，哪些不该碰
适合封装进存储过程的，是那些纯数据库内可完成、低开销、结果确定的检查；反之，涉及 OS 层、网络、磁盘 I/O 或跨实例比对的，一律交给外部脚本处理。
- ✅ 推荐封装：
sys.dm_db_index_physical_stats碎片率、sys.dm_exec_requests长事务、pg_stat_bgwriter检查点频率 - ❌ 别硬塞：
df -h磁盘空间（OS 命令）、ping主从延迟（网络层）、解析慢查询日志文件（文件 I/O + 文本处理） - ⚠️ 谨慎处理：统计信息更新时间（
stats_date()）在高并发下可能不准；建议加WITH (NOLOCK)或快照隔离，但要清楚这意味着可能读到旧值
为什么你写的巡检脚本总在凌晨失败
不是逻辑错，大概率是权限和上下文问题。存储过程默认以调用者身份执行，而巡检需要读取大量系统视图，普通应用账号通常没权限。
- SQL Server 必须显式授予
VIEW SERVER STATE和VIEW DATABASE STATE，不能只靠db_owner - PostgreSQL 中
pg_stat_*视图默认仅postgres用户可查，需用SECURITY DEFINER创建函数，并确保定义者有权限 - MySQL 的
PROCESS权限控制SHOW PROCESSLIST，但 8.0+ 默认关闭performance_schema，需确认performance_schema=ON且相关 consumers 已启用
最常被忽略的一点：巡检脚本里的 USE [dbname] 在跨库场景下极易失效，尤其当调度器以 master 或 postgres 数据库为默认上下文启动时——所有对象引用必须显式带库名前缀或用动态 SQL 切换上下文。
