mysql故障排查需遵循“先看现象、再抓证据、最后归因”的闭环节奏：第一步确认问题现象与影响范围；第二步同步检查错误日志、系统监控和mysql运行状态；第三步按连不上、查询慢、主从延迟分类深入；第四步快速止血、验证修复并复盘记录。
MySQL故障排查不是靠猜，而是有清晰节奏的闭环动作。核心是“先看现象、再抓证据、最后归因”，避免一上来就改配置或杀进程。
第一步：快速确认问题现象和影响范围
不能只听一句“数据库慢了”。要立刻厘清：
- 是完全连不上，还是部分SQL变慢？
- 是所有用户都卡，还是仅某个应用或某类操作（如查订单、导报表）异常？
- 故障是突然出现，还是缓慢恶化？最近是否升级、扩容、上线新SQL或调整过参数？
这一步决定后续排查方向——连不上就查网络和服务，慢查询就盯执行计划和资源争用。
第二步：优先检查三类关键证据
不翻日志、不看监控，等于蒙眼排障。必须同步查看：
-
错误日志（error log）：路径通常为
/var/lib/mysql/hostname.err，重点搜ERROR、CRITICAL、Aborted等关键词，它是故障的第一手线索； -
系统级监控：用
top、iostat、df -h确认CPU、内存、磁盘IO、空间是否打满； -
MySQL运行状态：执行
SHOW PROCESSLIST;看有没有大量Sleep连接或长事务阻塞，SHOW STATUS LIKE 'Threads_%';判断连接数是否逼近上限，SHOW VARIABLES LIKE 'max_connections';核对配置。
第三步：按故障类型分路深入
常见问题有明确排查路径，别跳步：
-
连不上（如ERROR 2002 / 1045 / 1130）：依次检查服务状态（
systemctl status mysqld）、端口监听（netstat -tuln | grep 3306）、防火墙（iptables -L -n）、用户权限（SELECT Host,User FROM mysql.user;）、DNS解析（确认是否漏配skip-name-resolve）； -
查询慢（如响应超时、QPS骤降）：打开慢日志（
SET GLOBAL slow_query_log = 'ON';），用mysqldumpslow定位TOP SQL，再用EXPLAIN分析执行计划，重点看是否走了索引、是否触发临时表或文件排序； -
主从延迟或中断：先查
SHOW SLAVE STATUS\G里的Seconds_Behind_Master、IO_Running、SQL_Running，再看错误信息（Last_IO_Error/Last_SQL_Error），常因网络抖动、主库binlog格式不一致或从库磁盘写满导致。
第四步：止血 + 验证 + 复盘
定位到根因后，动作要快准稳：
- 临时止血：比如
KILL掉长期占用资源的慢SQL，或mysqladmin flush-hosts解封被锁IP； - 验证修复：改完配置、加完索引、重启服务后，必须用原场景复现，确认问题消失；
- 记录复盘：把错误码（如1129、145）、触发条件、解决动作、预防建议记入内部Wiki，避免同类问题重复发生。
