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）
