必须组合查看连接数、活跃线程、慢查询、锁等待、缓冲池命中率五类指标，单看易误判；优先用mysqladmin ping确认服务存活，再分层诊断。
直接结论：别只连上去跑 SHOW STATUS，先用 mysqladmin ping 确认服务活着，再分层查——连接数、活跃线程、慢查询、锁等待、缓冲池命中率，这五类指标必须组合看，单看一个容易误判。
怎么快速确认 MySQL 进程是否真在运行
很多人一上来就 mysql -u root -p 登录，结果连不上才怀疑挂了——其实浪费时间。真正轻量、可靠的探测方式是 mysqladmin ping：
- 成功时只输出
mysqld is alive，失败直接报错（如Can't connect to local MySQL server） -
Access denied≠ 服务宕机，只是账号没权限；只有Can't connect才说明进程未启动、端口未监听或 socket 路径错误 - Linux 下默认走本地 socket，无需参数；远程或自定义路径时必须加
-h、-P、-S，例如：mysqladmin -h 127.0.0.1 -P 3306 -u monitor -p ping
查连接和活跃线程：Threads_connected 和 Threads_running 是关键
新手常盯着 Connections（总连接次数），但它包含已断开的连接，不能反映当前负载。真正要盯的是：
-
SHOW STATUS LIKE 'Threads_connected'：当前打开的连接数，接近max_connections值时新连接会被拒绝 -
SHOW STATUS LIKE 'Threads_running'：正在执行 SQL 的线程数，持续 >5–10 就该警惕慢查询堆积；超过 CPU 核心数 80% 通常意味着瓶颈 -
SHOW STATUS LIKE 'Aborted_connects'：持续上涨说明客户端频繁连不上，可能是密码错、host 不符、max_connect_errors触发锁定，或防火墙拦截
揪出卡住的查询：SHOW FULL PROCESSLIST 比 SHOW PROCESSLIST 更可靠
SHOW PROCESSLIST 默认只返回前 100 条，容易漏掉后台长事务或 Sleep 状态的空闲连接。必须用：
-
SHOW FULL PROCESSLIST查全量（注意：FULL关键字不能省） - 重点关注
Time列（单位秒）和State列：Sending data、Copying to tmp table、Locked且Time > 60的线程大概率有问题 - 高并发下别反复执行——它本身会加锁读取内部结构，可能加剧延迟；更安全的方式是：
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query' AND TIME > 30 ORDER BY TIME DESC
缓存与锁：Innodb_buffer_pool_reads 和 Innodb_row_lock_waits 必须定期比对
这两个指标单独看意义不大，必须结合对应基数计算比率：
- 缓冲池命中率：
Innodb_buffer_pool_read_requests / (Innodb_buffer_pool_read_requests + Innodb_buffer_pool_reads)，低于 99% 就该考虑调大innodb_buffer_pool_size - 行锁等待频率：
Innodb_row_lock_waits持续上涨，配合Innodb_row_lock_time_avg看平均等待时长，>50ms 就需检查事务粒度或索引缺失 - 别只查一次——建议每小时采集一次
SHOW GLOBAL STATUS，建立基线值，突变才真正值得干预
最易被忽略的点：Uptime 和 error.log。服务“在线”不等于“稳定”，Uptime 短（比如刚重启）、error.log 里有重复的 Aborted connection 或 InnoDB: Error，才是“假在线”的信号。监控不是看它有没有心跳，而是看心跳是否规律、有力。
