数据库巡检最怕做成“走过场”。很多人拿着检查表一项项打勾，CPU正常、内存正常、磁盘没满，就认为数据库是安全的。这种巡检方式在真实生产环境里基本等于没检。真正的安全巡检要回答三个问题：数据库现在有没有正在发生的异常、哪些隐患会在未来几天内爆发、现有的备份和权限体系能不能扛住一次真实故障。围绕这三个问题，巡检才有实际价值。
先看连接数和会话状态，这是最直接的“当前异常”指标
登录数据库后第一件事不是看慢查询，而是看当前有多少连接、这些连接在干什么。很多性能问题和安全事件的第一现场就在会话列表里。以MySQL为例，执行
SHOW PROCESSLIST;可以快速看到所有活跃连接。重点关注State列为Locked、Sending data时间过长、或者同一个用户短时间内建立了大量连接的会话。如果发现某个应用账号的连接数异常飙升，很可能是连接池配置失效，或者有人在批量拖数据。PostgreSQL里用
SELECT * FROM pg_stat_activity WHERE state = 'active';查看活跃会话，重点看wait_event_type为Lock或LWLock的会话，这些会话正在等待锁，往往是阻塞链的源头。
连接数本身也要和历史基线对比。如果平时业务高峰连接数是200，今天突然到500，不要急着调大max_connections，先查是不是有新的上线任务、报表任务或者爬虫在打库。盲目调大连接数只会把数据库推向资源耗尽。巡检时记录当前连接数和历史同期的差异，比单纯看一个绝对值有用得多。
锁等待和长事务是隐蔽但致命的问题
锁等待在巡检时很容易被忽略，因为它的影响是渐进的。一个事务持有行锁不释放，后面的事务开始排队，排队的事务又持有自己的锁，最终形成锁链。等到业务方反馈“系统卡了”的时候，数据库可能已经积压了几百个等待会话。巡检时要主动查锁等待情况。MySQL 8.0可以用
SELECT * FROM sys.innodb_lock_waits;直接看等待关系。PostgreSQL用
SELECT pid, now() - xact_start AS duration, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY duration DESC;找出运行时间最长的活跃事务。
长事务比锁等待更值得警惕。一个事务开启后运行了半小时还没提交，即使它没有阻塞别人，也意味着它持有的undo日志或者旧版本数据无法清理，可能导致表空间膨胀、主从延迟加大。巡检时如果发现长事务，要记录事务的开始时间、来源IP、执行的SQL，判断是正常的批处理任务还是异常操作。对于超过阈值的长事务，要有告警机制，而不是等巡检时才发现。
慢查询和资源消耗要结合执行计划看，不能只看数量
慢查询日志是巡检的常规项目，但只看慢查询数量没有意义。一条SQL执行10秒，如果一天只跑一次，影响有限；一条SQL执行0.5秒，如果一秒跑100次，对数据库的压力远超前者。巡检时要看慢查询的累计影响，也就是执行次数乘以平均耗时。MySQL可以用pt-query-digest分析慢日志，找出总耗时最高的SQL。PostgreSQL可以查pg_stat_statements视图，按total_time排序。
找到高消耗SQL后，必须看执行计划。同样的SQL，数据量变化后执行计划可能完全改变。巡检时重点看是否出现了全表扫描、索引失效、嵌套循环连接行数过大等情况。MySQL用
EXPLAIN ANALYZE可以看到实际执行统计，PostgreSQL同样支持
EXPLAIN (ANALYZE, BUFFERS)。执行计划里rows估算值和实际返回行数差异过大，说明统计信息已经过时，需要重新收集。这些细节在巡检时发现并处理，能避免很多线上事故。
存储空间和增长趋势要提前预判，而不是等报警
磁盘空间检查是巡检的必做项，但很多人只看剩余空间百分比。更关键的是增长趋势。如果磁盘剩余20%，但每天增长2%，那么10天后就会耗尽。巡检时要记录当前数据文件大小、日志文件大小、临时文件大小，并和上次巡检的数据对比，算出日均增长量。对于MySQL的binlog、PostgreSQL的WAL文件，要确认清理策略是否正常生效。很多磁盘爆满事故不是数据增长太快，而是日志文件没有及时清理，或者归档失败导致日志堆积。
表空间碎片也是容易被忽视的问题。频繁的删除和更新操作会导致表内部产生大量碎片，实际数据只有50GB，但表文件占了80GB。巡检时可以用
SELECT table_name, data_free FROM information_schema.tables WHERE data_free > 0 ORDER BY data_free DESC;查看MySQL表的碎片情况。PostgreSQL可以用pgstattuple扩展检查表膨胀程度。碎片过多不仅浪费空间，还会降低扫描效率。对于确认有大量碎片的表，安排在线重建，但要评估重建期间的锁影响和主从延迟风险。
备份有效性是安全巡检的底线，必须做恢复验证
备份检查不能只看备份任务是否成功。备份文件存在不代表能恢复。巡检时要实际做一次恢复演练，哪怕只是恢复到一台测试机。验证备份文件的完整性、恢复流程的可行性、恢复时间是否满足业务要求。很多团队平时备份任务都显示成功，真到故障时才发现备份文件损坏、恢复脚本报错、或者恢复时间需要8小时而业务只能容忍2小时。这些问题的暴露时机不应该在故障当天。
对于MySQL，要检查binlog是否开启、binlog保留时间是否足够覆盖恢复窗口。对于PostgreSQL，要检查WAL归档是否正常、基础备份和WAL的连续性是否完整。巡检时还要确认备份文件是否存放在独立的存储上，和生产数据库不在同一台物理机或同一个云盘。如果备份和生产数据放在一起，一旦硬件故障或误删除，备份也一起丢了。
权限和账号审计要关注“谁能做什么”而不是“谁有多少权限”
数据库权限巡检最常犯的错误是只统计账号数量和权限级别，不关注权限的实际使用情况。一个拥有SUPER权限的账号，如果半年没有登录过，这个权限就是纯粹的风险。巡检时要列出所有账号，标注最后登录时间、来源主机、拥有的权限，找出长期未使用的高权限账号并回收。对于应用账号，要确认是否遵循最小权限原则，应用账号是否拥有DROP、TRUNCATE、GRANT等危险权限。
MySQL 8.0引入了角色管理，巡检时要检查角色分配是否合理，是否有账号直接拥有过高的全局权限而不是通过角色继承。PostgreSQL要检查pg_hba.conf的认证规则，确认是否允许了不必要的远程访问，密码存储是否使用了scram-sha-256而不是md5。对于云数据库，还要检查是否开启了公网访问，公网访问是否限制了来源IP。数据库直接暴露在公网上是极其危险的做法，巡检时必须列为高危项。
主从复制和集群健康状态要深入检查延迟原因
如果数据库做了主从复制或集群，巡检时不能只看从库状态是否正常。要深入检查主从延迟的具体数值和延迟原因。MySQL用
SHOW SLAVE STATUS;查看Seconds_Behind_Master，但这个值只是一个粗略估计，实际延迟可能更大。更准确的方法是对比主从库上同一个时间戳的binlog位置。PostgreSQL用
SELECT * FROM pg_stat_replication;查看复制状态，关注write_lag、flush_lag、replay_lag三个指标。
主从延迟的原因很多，可能是从库硬件性能差、从库上跑了大量查询、大事务导致回放慢、网络带宽不足。巡检时要根据延迟的具体表现判断原因。如果延迟在业务高峰期增大，低峰期恢复，说明从库承载了过多读流量，需要扩容或分流。如果延迟持续增长不恢复，可能是从库回放线程卡住，需要检查是否有锁冲突或DDL操作。主从延迟超过一定阈值时，从库的读请求应该被自动摘除，否则业务会读到过期数据。
参数配置巡检要结合业务特点，不能照搬默认值
数据库参数配置是巡检中技术含量较高的部分。很多参数默认值并不适合生产环境，尤其是内存相关参数。MySQL的innodb_buffer_pool_size应该设置为物理内存的60%到70%，但很多环境还是默认的128MB，导致大量数据从磁盘读取，性能极差。PostgreSQL的shared_buffers、effective_cache_size、work_mem等参数也要根据实际内存和业务类型调整。巡检时要记录关键参数的值，并和推荐值对比。
除了性能参数，安全相关参数更要重点检查。MySQL的local_infile是否关闭、secure_file_priv是否设置了限制目录、skip_name_resolve是否开启以避免DNS解析带来的安全隐患。PostgreSQL的ssl参数是否开启、password_encryption是否为scram-sha-256、log_connections是否开启以记录所有连接尝试。这些参数直接关系到数据库的安全边界，巡检时发现不合规配置要立即整改。
日志审计要确认“发生了什么”能被追溯
数据库日志是安全事件发生后追溯的唯一依据。巡检时要确认错误日志、慢查询日志、审计日志是否正常开启，日志内容是否完整。MySQL的错误日志要检查是否有频繁的警告信息，比如连接中断、表损坏、内存分配失败等。PostgreSQL的日志要检查是否记录了所有DDL操作、连接和断开事件、错误SQL。很多安全规范要求数据库开启审计功能，记录所有敏感操作，包括登录、权限变更、数据导出、结构变更等。
日志保留时间也要检查。如果日志只保留7天，而安全审计要求追溯90天，这就是合规风险。巡检时要确认日志的轮转策略、保留周期、存储位置是否满足要求。日志文件本身也要防止被篡改，建议将日志同步到独立的日志服务器或对象存储，数据库本地只保留短期日志。一旦发生安全事件，本地日志可能被攻击者删除，远程日志就是唯一的证据。
自动化巡检脚本比人工检查更可靠，但要持续维护
人工巡检容易遗漏，而且每次巡检的质量取决于执行人的经验和状态。建立自动化巡检脚本，把上述检查项固化成可重复执行的程序，是更可靠的做法。脚本可以定期运行，输出巡检报告，发现异常时自动告警。比如每天凌晨检查一次连接数、锁等待、长事务、慢查询、磁盘空间、备份状态、主从延迟，将结果写入报告并发送给DBA。
自动化巡检脚本需要持续维护，因为数据库版本升级、业务变化、架构调整都会影响检查项的有效性。脚本里写死的阈值要根据实际情况调整，不能设置得太宽松导致漏报，也不能太严格导致告警泛滥。一个好的巡检脚本应该具备基线学习能力，能够根据历史数据判断当前状态是否异常，而不是简单地和固定阈值比较。巡检自动化的目标不是替代人工，而是让人工把精力集中在脚本发现的异常上，做深入分析和处理。
数据库日常运维安全巡检的核心不是完成检查项，而是通过系统化的检查发现潜在风险，在问题演变成事故之前处理掉。每次巡检都应该有明确的结论和后续行动项，而不是一份“一切正常”的报告。真正的安全来自于对细节的持续关注和对异常的快速响应。
