本篇通过典型故障场景的还原与分析，帮助你掌握高效、系统的 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） |
| 容灾 | 异地备份 + 备库，确保快速恢复 |
五、总结
MySQL 故障是不可避免的，但有章可循。通过掌握故障模式、排查流程和恢复手段，可最大限度降低业务中断的风险。
建议：
-
每种场景做一份“应急文档”；
-
搭建故障演练环境；
-
定期压测、巡检、SQL Review。
