SQL数据库巡检核心是将关键健康指标自动化，聚焦可用性（连接成功率、主从延迟、写入响应）、性能（活跃会话、锁等待、慢查询）及数据安全（磁盘空间、碎片率、行数波动）三大刚性维度，通过轻量稳定脚本实现采集、告警与追溯。
SQL数据库巡检不能只靠人工点查，核心是把关键健康指标变成可采集、可告警、可追溯的自动化流程。重点不在“全”，而在“准”——抓住影响可用性、性能和数据安全的刚性指标，用轻量方式持续运行。
核心可用性指标：连得上、读得通、写得进
这是巡检的第一道防线。不能只看数据库进程是否存活，必须模拟真实业务行为验证端到端可用性。
-
连接成功率：每5分钟用最小权限账号（如只读用户）发起连接+简单查询（
SELECT 1），失败连续2次立即告警 -
主从同步延迟：对MySQL查
Seconds_Behind_Master，PostgreSQL查pg_replication_slot_advance()或复制积压字节数，阈值建议≤60秒 - 写入响应时间基线：在低峰期执行标准INSERT（如插入单行测试记录），记录P95耗时作为基线，实时值超基线3倍即触发预警
性能瓶颈指标：盯住资源争用与慢操作
性能问题往往有征兆。避免等业务报障才介入，要提前捕获资源饱和信号和SQL异常模式。
-
活跃会话数突增：监控
SHOW PROCESSLIST（MySQL）或pg_stat_activity（PG）中state=‘active’的数量，设置动态阈值（如过去1小时均值×2.5） -
锁等待超时频次：抓取
innodb_row_lock_waits（MySQL）或pg_locks中blocked状态会话数，10分钟内≥5次即标记风险 - 慢查询增长率：解析慢日志（或使用performance_schema/PG log_statement），统计每15分钟执行时间＞1秒的SQL数量，环比增长＞200%自动归档并推送摘要
数据安全与容量指标：防丢、防满、防误
数据是底线。容量和一致性问题不会立刻崩溃，但后果严重，必须建立硬性水位线和校验机制。
- 磁盘剩余空间：不仅看数据库目录，还要监控事务日志路径、备份临时目录；剩余＜15%触发预警，＜8%强制只读保护（通过修改全局变量或应用层拦截）
-
表碎片率：MySQL用
DATA_FREE / DATA_LENGTH计算，PG用pg_total_relation_size() - pg_table_size()，单表碎片＞30%且体积＞1GB时列入优化队列 -
关键表行数波动：对用户、订单、账户等核心表，每日凌晨比对
COUNT(*)与前3天均值，偏差＞15%自动触发数据一致性快照比对（如MD5聚合校验）
自动化实现要点：轻量、稳定、可运维
脚本不是越复杂越好，关键是能长期无人值守运行，并让问题可定位。
- 统一采集入口：用Python + SQLAlchemy封装通用连接池，适配MySQL/PG/SQL Server，避免各库写重复逻辑
-
结果存档结构化：每次巡检结果写入独立表（如
db_health_log），字段含：实例ID、指标名、原始值、状态（OK/WARN/CRIT）、采集时间、告警等级 - 告警分级不轰炸：WARN级（如碎片率超限）发企业微信/钉钉；CRIT级（如主从延迟＞300秒或连接失败）电话+短信双触达，并自动创建工单
- 自愈能力留接口：对可预判场景（如临时表空间满），预留调用清理脚本的钩子，但默认关闭，需人工确认后启用
不复杂但容易忽略。真正落地的关键，是把指标和业务影响挂钩——比如“连接失败”对应登录页白屏，“主从延迟”对应订单查询旧数据。巡检不是生成报表，而是守住服务水位线。
