当前位置：首页 > backend >正文

第十四篇：MySQL 运维中的故障场景还原与排查实战技巧

backend 2025/7/18 14:32:51

本篇通过典型故障场景的还原与分析，帮助你掌握高效、系统的 MySQL 故障排查与应急处理方法，构建稳定可靠的数据库运维体系。

一、故障排查的基本思路

快速定位问题入口：
- 错误日志、连接报错、监控告警；
确认影响范围：
- 是否为单点问题？是否影响主从、业务系统？
分析核心指标：
- 磁盘、CPU、内存、连接、QPS、锁、慢查询；
执行缓解措施：
- 临时限流、kill 连接、读写切换；
后续根因追踪与优化。

二、典型故障场景实战分析

1. 场景一：连接过多，系统响应慢甚至拒绝连接

现象：

报错：Too many connections
后台接口访问超时；
CPU 飙高，QPS 降低。

排查步骤：

SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';

应对措施：

临时提升最大连接数（不建议长期）：

SET GLOBAL max_connections = 1000;

杀掉空闲连接：

SHOW PROCESSLIST; KILL 连接ID;

根因分析：是否有连接未关闭或连接池配置不当；
长期优化：使用连接池、优化慢查询、防止大事务。

2. 场景二：主从复制中断

现象：

从库 Seconds_Behind_Master 持续增长；
Slave_IO_Running 或 Slave_SQL_Running 为 No。

诊断命令：

SHOW SLAVE STATUS\G;

常见报错与应对：

错误信息	原因	解决方案
`Duplicate entry`	主库数据变更，从库已有相同数据	跳过错误 `SET GLOBAL sql_slave_skip_counter=1`
`Relay log read failure`	中继日志损坏	重建复制
`IO thread could not connect`	网络故障/账号权限问题	检查网络、防火墙、用户权限

3. 场景三：磁盘写满导致数据库崩溃

现象：

服务卡死；
错误日志出现 InnoDB: Write to file failed.

应对措施：

df -h 检查磁盘；
清理日志文件，如旧 binlog：

PURGE BINARY LOGS TO 'mysql-bin.000123';

临时转移部分文件，如备份转移到其他磁盘；
检查是否存在表空间碎片、临时文件未清理。

4. 场景四：锁等待导致性能下降甚至死锁

现象：

接口访问慢；
SHOW PROCESSLIST 中大量 Waiting for lock。

分析工具：

SHOW ENGINE INNODB STATUS;

解决方法：

杀死占锁连接：

KILL ID;

优化 SQL：加索引、控制事务粒度；
避免长事务与锁冲突操作交织；
使用行级锁代替表锁。

5. 场景五：慢查询暴增，QPS/TPS 急剧下降

定位手段：

慢日志分析：

SHOW VARIABLES LIKE 'slow_query_log%'; pt-query-digest /path/to/slow.log

关注是否有新的 SQL 被频繁执行、是否缺失索引；
EXPLAIN 分析执行计划。

应对策略：

增加必要索引；
拆解复杂查询；
加缓存（如 Redis）降低 DB 压力。

三、故障日志分析技巧

日志文件位置：

文件	作用
error.log	MySQL 错误、启动、崩溃信息
slow.log	慢查询
binlog	二进制日志（数据变更）
relaylog	中继日志（从库用）

常见关键字：

InnoDB: Deadlock found
Too many connections
Disk full
Slave_IO_Running: No

四、预防与优化建议

方面	建议
监控	建立 Prometheus + Grafana 指标告警系统
自动化	故障切换用 MHA、Orchestrator 管理主从
慢查询治理	定期分析慢日志、自动推送优化建议
审计	审计关键操作（如 DROP、GRANT）
容灾	异地备份 + 备库，确保快速恢复