MySQL日常运维需掌握核心命令：SHOW PROCESSLIST查连接，SHOW SLAVE STATUS\G诊主从，SHOW ENGINE INNODB STATUS\G析InnoDB，结合information_schema与系统命令定位故障。

MySQL日常运维中，快速定位和解决故障离不开一套熟练掌握的基础命令。重点不是背诵所有参数，而是理解每个命令在什么场景下能帮你看到关键信息——比如连接异常看 SHOW PROCESSLIST，性能卡顿查 SHOW ENGINE INNODB STATUS，主从不同步盯 SHOW SLAVE STATUS\G。

查看连接与会话状态

连接数暴增、线程卡死、慢查询堆积时，第一步就是摸清当前活跃会话。

• SHOW PROCESSLIST; 查看所有连接（普通用户只能看到自己的）；加 FULL 可显示完整 SQL（SHOW FULL PROCESSLIST;）
• SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep'; 过滤掉空闲连接，聚焦运行中的操作
• KILL [ID]; 终止指定线程（如 KILL 12345;），谨慎用于长时间运行的非关键查询
• 配合 netstat -an | grep :3306 或 ss -tuln | grep :3306 看外部连接来源和端口占用情况

检查主从复制健康度

主从延迟、IO/SQL线程中断、GTID不一致等问题都藏在复制状态里。

• SHOW SLAVE STATUS\G 是核心命令，重点关注：
  Slave_IO_Running 和 Slave_SQL_Running 是否为 Yes；
  Seconds_Behind_Master 是否持续增长；
  Retrieved_Gtid_Set 与 Executed_Gtid_Set 是否一致（GTID模式下）；
  Last_IO_Error / Last_SQL_Error 是否有报错内容
• 若 IO 线程停止，先检查主库网络连通性、复制账号权限、binlog 文件是否存在；SQL 线程停止多因语句冲突或表结构不一致
• STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; 仅限测试环境跳过单条错误（GTID 模式下需用 gtid_next 方式）

分析 InnoDB 存储引擎状态

锁等待、事务阻塞、缓冲池压力、崩溃恢复等问题，INNODB STATUS 是最直接的诊断入口。

• SHOW ENGINE INNODB STATUS\G 输出长文本，重点看：
  SEMAPHORES 段是否频繁出现 wait；
  TRANSACTIONS 段是否有长事务（Trx has been waiting）或未提交事务；
  LATEST DETECTED DEADLOCK 记录最近死锁详情；
  BUFFER POOL AND MEMORY 中 Free buffers 是否长期过低
• 结合 SELECT * FROM information_schema.INNODB_TRX; 查当前运行事务，配合 INNODB_LOCK_WAITS 和 INNODB_LOCKS（MySQL 8.0+ 已移除后者）定位锁源
• 若发现大量 lock struct(s) 占用，可查 performance_schema.data_locks（8.0+）获取更细粒度锁信息

基础性能与配置快检

响应变慢、内存飙升、磁盘写满？先确认 MySQL 自身配置和资源使用是否合理。

• SHOW VARIABLES LIKE '%buffer%'; 关注 innodb_buffer_pool_size（建议设为物理内存 50%–75%）、sort_buffer_size、join_buffer_size 是否过大导致内存争抢
• SHOW GLOBAL STATUS LIKE 'Threads_%'; 查 Threads_connected（当前连接数）、Threads_running（活跃线程数），对比 max_connections 防止打满
• SHOW GLOBAL STATUS LIKE 'Innodb_row%'; 看 Innodb_rows_read/updated/deleted/inserted 判断读写负载趋势
• df -h + du -sh /var/lib/mysql/* 快速检查磁盘空间，特别关注 ib_logfile*、binlog 和临时表目录（tmpdir）