数据库巡检三张表：磁盘、连接、慢查询

多数数据库故障在爆发前，指标早就有苗头，巡检做的就是把苗头每天扫一遍。对 MySQL 来说，日常巡检盯住三张"表"：磁盘、连接、慢查询。 磁盘看什么 看余量和增速两样： df -h /var/lib/mysql 余量低于两成就该安排扩容或清理，别等写满——磁盘写满的数据库会直接拒绝写入。binlog 配上过期时间，比如保留七天，不少磁盘写满事故就是它无限累积造成的。增速用 ls -lh 看数据目录和 binlog 的单日增量，按当前速率倒推还能撑多少天，提前排期，比临时救火从容得多。 连接看什么 mysql -e "SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';" 经验阈值：持续连接数超过 max_connections 的七成，就要查有没有连接泄漏（应用没正确释放连接），或者该上连接池了。偶发尖峰不用紧张，连续几小时高位必须处理。看连接还要看来源：按来源地址分组数一遍，某个地址占了大头，顺着就能找到没释放连接的应用。顺带看 Threads_running，长期大于 CPU 核数说明并发压力已经压到执行层，该优化 SQL 或扩容了。 慢查询看什么 确认慢日志开着：SHOW VARIABLES LIKE 'slow_query_log';，long_query_time 从 1 秒起步观察。每天看一眼慢日志条数，突然增多就是变化信号。更进一步用 pt-query-digest 做汇总分析： pt-query-digest 慢日志文件 | head -50 重点抓两类：出现次数最多的和总耗时最长的，逐条安排优化。优化完记一条前后耗时对比，这类记录攒多了，容量评估时都是依据。 异常的下一步 三项里任何一项异常，动作顺序是：先判断影响面（现在有没有伤到业务），再找变化点（昨天发了什么版本、改了什么配置），最后才是调参数。巡检的价值不在看，而在看出来的异常有人跟进到关闭。把三张表的检查写成每日自动脚本，输出摘要推到群里，巡检这件事才坚持得下去。