SQL数据库健康检查需自动化巡检连接状态、查询性能与存储IO三大核心指标：活跃连接超70%阈值、idle in transaction会话、P95/P99延迟突增、全表扫描率升高、执行计划异常、表空间>85%、WAL延迟>30分钟或IOPS超80%均触发告警。
SQL数据库健康检查的核心在于通过自动化巡检关键指标，提前发现潜在风险，避免突发故障。重点不是等出问题再救火，而是让系统自己“说”哪里不舒服。
连接与会话状态
活跃连接数、空闲连接数、等待连接数是判断数据库是否过载的第一道关口。连接池打满、大量会话卡在“waiting”状态，往往预示着锁争用或慢查询积压。
- 监控阈值建议：活跃连接数持续超过最大连接数的70%，触发告警
- 重点关注red">state = 'idle in transaction'的会话——它们可能持有锁却没提交，是隐藏的死锁源头
- 自动巡检脚本应定期查
pg_stat_activity（PostgreSQL）或sys.dm_exec_sessions（SQL Server），过滤出异常会话并记录
查询性能瓶颈
慢查询是数据库亚健康的最常见表征。光看平均响应时间不够，得盯住P95/P99延迟、全表扫描率、执行计划突变这三类信号。
- 每天自动采集
pg_stat_statements（PG）或查询存储（SQL Server）中耗时Top 10的SQL，对比前7天基线，波动超200%即标记 - 对执行频率高但未走索引的语句，自动标记为“优化待办”，附带缺失索引建议（如PG的
pg_stat_all_indexes分析） - 识别“隐式类型转换”导致索引失效的典型模式，例如
WHERE user_id = '123'（字段是int型）
存储与IO压力
磁盘写满、IO等待飙升、WAL堆积，常在凌晨批量任务后集中爆发。这些指标变化缓慢但后果严重，必须前置拦截。
- 表空间使用率>85%、WAL归档延迟>30分钟、IOPS持续超设备能力80%，三项任一满足即告警
- 自动巡检需关联分析：高IO等待+低缓存命中率（
shared_buffers_hit_ratio - 对增长过快的表（如日志表），自动识别并提示分区或归档策略，避免单表超GB级无管控
复制与高可用状态
主从延迟、同步节点掉线、WAL发送/接收中断，直接影响故障切换能力和数据一致性。不能只靠“绿灯”状态，要看数字是否可信。
- MySQL主从延迟监控必须用
Seconds_Behind_Master+SHOW SLAVE STATUS中的Read_Master_Log_Pos和Exec_Master_Log_Pos交叉验证 - PostgreSQL流复制中，
pg_stat_replication里的write_lag/flush_lag超5秒需关注；同步备库sync_state != 'sync'要立即通知 - 自动巡检脚本应模拟心跳检测：向主库写入带时间戳的测试记录，10秒内在所有备库查到才算链路正常
