MySQL：MySQL日常运维
发布时间:2026-04-25 08:01
一、前言
搞过的人都知道，MySQL跑着跑着哪天突然连不上、慢查询爆炸、磁盘报警，那种绝望感。日常运维本质就三件事：快速定位问题、快速止血恢复、别让同一坑坑死两次。以下是真实环境磨出来的套路，不讲理论，直接上操作。
二、操作步骤
第1步：确认MySQL进程还活着
ps aux | grep mysqld | grep -v grep
mysql 12345 0.2 3.2 1234567 524288 ? S 10:00 1:23 /usr/sbin/mysqld --user=mysql
有输出说明进程在，看到空或只有grep自己说明MySQL已经归西。
第2步：本地socket连接测试（网络不通时必杀技）
mysql -u root -p -S /var/lib/mysql/mysql.sock
Enter password: YOUR_PASSWORD
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 125
Server version: 8.0.32 MySQL Community Server
mysql>
mysql -u root -pYOUR_PASSWORD -e "SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections';"
Threads_connected: 147
max_connections: 500
147/500还算安全，如果飙到480+，等着应用报too many connections吧。
第4步：揪出当前正在跑啥SQL
mysql -u root -pYOUR_PASSWORD -e "SHOW PROCESSLIST;"
+----+------+-----------+------+---------+------+----------+---------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+------+---------+------+----------+---------------------+
| 58 | app | 10.0.0.15 | prod | Sleep | 120 | | NULL |
| 89 | app | 10.0.0.22 | prod | Query | 45 | executing| SELECT * FROM orders|
+----+------+-----------+------+---------+------+----------+---------------------+
看到Time列时间很长的Query基本就是罪魁祸首，Kill掉命令是KILL 89;
第5步：开启并分析慢查询日志
mysql -u root -pYOUR_PASSWORD -e "SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 2; SHOW VARIABLES LIKE 'slow_query_log%';"
+---------------------+----------------------------------+
| Variable_name | Value |
+---------------------+----------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/slow-query.log |
+---------------------+----------------------------------+
CentOS/RHEL路径通常是/var/lib/mysql/slow-query.log，Ubuntu默认在/var/log/mysql/slow-query.log，别找错地方。
第6步：查看表大小和索引使用情况（磁盘告警时必查）
mysql -u root -pYOUR_PASSWORD -e "SELECT table_schema, table_name, (data_length + index_length)/1024/1024 AS size_mb FROM information_schema.tables ORDER BY size_mb DESC LIMIT 10;"
+---------------+------------+------------+
| table_schema | table_name | size_mb |
+---------------+------------+------------+
| prod | order_log | 4821.32 |
| prod | access_log | 1204.56 |
+---------------+------------+------------+
order_log单表快5G，要么归档清理要么考虑分表，别等磁盘写满再处理。
第7步：快速全量备份（生产环境每日必做）
mysqldump -u root -pYOUR_PASSWORD --single-transaction --master-data=2 --routines --triggers --all-databases | gzip > /backup/mysql_full_$(date +%Y%m%d).sql.gz
Warning: Using a password on the command line interface can be insecure.
-- Dump completed on 20240115 03:00:12
⚠️ 警告：生产环境建议用--defaults-extra-file读取密码文件，别把密码挂命令行里，容易被history记录泄露。
三、常见问题FAQ
Q：应用连不上MySQL，报Can't connect to MySQL server，但进程明明活着
A：先netstat -tlnp | grep 3306看端口监听。mysqld进程在不代表在跑TCP监听——socket模式启动或bind-address绑死了网卡。另一个大坑：云服务器安全组/防火墙没放行3306端口，网络层被拦了应用层根本看不到。逐层ping、telnet端口测试，别上来就怀疑MySQL配置。
Q：MySQL重启后密码忘了，root进不去，咋整
A：先试skip-grant-tables单用户模式重启：mysqld_safe --skip-grant-tables &，然后无密码登录改密码。⚠️警告：生产环境用这招等于暂时关闭权限校验，期间任何人都能连进来，改完记得重启恢复正常模式。如果是MySQL 8.0+，ALTER USER语法变了，别套用老命令。
Q：慢查询日志开了一直没动静，怎么确认有没有真的抓到慢SQL
A：SHOW VARIABLES LIKE 'slow_query_log%';确认日志文件路径，然后ls -lh /var/lib/mysql/slow-query.log看文件大小有没有变化。另一个坑：long_query_time默认是10秒，业务SQL普遍快的话根本不会写进去，调成1秒先跑几天再分析，别一上来就追求0.5秒那精度。
Q：主从复制断了，怎么快速判断谁的问题
A：在从库执行SHOW SLAVE STATUS\G，重点看三列：Slave_IO_Running、Slave_SQL_Running、Last_SQL_Errno。IO不跑一般是网络或权限问题，SQL不跑是执行SQL出错。先记下Last_Error里的错误代码，去官方文档或搜索引擎查，别瞎猜。重置复制链路用RESET SLAVE ALL;重新CHANGE MASTER TO，但丢数据风险自担。
四、总结
核心要点：MySQL日常运维三板斧——进程状态随时查、连接数设上限别裸奔、慢查询日志定期分析。备份是最后的防线，每日全量+binlog增量才是靠谱组合。遇到故障先确认进程+端口+socket三层连通性，别上来就重启服务治标不治本。
延伸阅读：