mysqladmin 是最轻量、最贴近运维场景的实时检查工具，支持 ping 测连通性、extended-status 动态监控关键指标、processlist 快速查看线程状态；结合 5 个核心 show status 指标、show full processlist 三列分析、错误与慢查询日志轮转抽检及 mysqldumpslow 分析，可构建完整因果诊断链。
直接用 mysqladmin 查看实时状态
别先登录 MySQL 再敲一堆 SHOW 命令，mysqladmin 是最轻量、最贴近运维场景的实时检查工具。它不依赖客户端连接状态，能快速验证服务是否真正在响应请求。
常用组合：
-
mysqladmin -u root -p ping：只测连通性，返回mysqld is alive才算真正可用；如果进程卡住但没退出，systemctl status mysql会显示 active，但这个命令会失败 -
mysqladmin -u root -p extended-status -i 2：每 2 秒刷新一次全局状态，重点关注Threads_connected、Threads_running、Queries和Slow_queries这几行变化 -
mysqladmin -u root -p processlist：比SHOW PROCESSLIST更快，输出更紧凑，适合快速扫一眼有没有Locked或长时间Sending data的线程
登录后重点查这 5 个 SHOW STATUS 指标
很多团队一上来就 SHOW STATUS 全量输出，几百行里找关键值效率极低。实际只需盯住以下 5 个变量，就能覆盖 80% 的异常初判：
-
Threads_connected：当前连接数。持续高于应用配置的连接池上限（比如 Druid 默认 20），说明连接泄漏或下游未正确 close -
Threads_running：活跃线程数。若长期 > CPU 核心数 × 2，大概率存在慢查询或锁竞争 -
Aborted_clients和Aborted_connects：非正常断连数。前者突增说明客户端超时或网络抖动，后者突增往往指向认证失败或 max_connections 耗尽 -
Created_tmp_disk_tables：磁盘临时表数量。该值上升伴随Sort_merge_passes增加，基本可断定是排序/JOIN 缺少合适索引
SHOW PROCESSLIST 不只是看“谁在跑”，要看“卡在哪”
执行 SHOW FULL PROCESSLIST（注意加 FULL）后，别只扫 SQL 文本。真正要盯的是三列：
-
Time：超过 60 秒的线程必须人工介入；若大量线程Time在缓慢递增且State停在Waiting for table metadata lock，大概率是 DDL 操作阻塞了 DML -
State：常见高危状态包括Locked（MyISAM 表级锁）、Waiting for lock（InnoDB 行锁等待）、Copying to tmp table（内存不足被迫落盘） -
Info：截断内容可能掩盖关键信息，FULL参数才能看到完整 SQL —— 但生产环境慎用，大结果集可能拖慢整个连接
错误日志和慢查询日志不是“出了问题才看”
这两类日志必须配置轮转并定期抽检，否则出事时再翻就是大海捞针：
- 错误日志路径由
log_error变量决定，常见位置是/var/log/mysql/error.log或数据目录下的hostname.err；重点搜InnoDB: Cannot allocate memory、Got an error reading communication packets这类底层报错 - 慢查询日志需显式开启：
slow_query_log = ON+long_query_time = 1（别设 0，否则日志爆炸）；启用后立刻检查slow_query_log_file路径是否可写，否则日志静默失效 - 不要等 DBA 人工分析日志 —— 用
mysqldumpslow -s t -t 10 /path/to/slow.log直接提取耗时 Top 10 查询，再结合EXPLAIN看执行计划
真正的难点不在命令怎么敲，而在于把零散指标串成因果链：比如 Threads_running 飙升 → SHOW PROCESSLIST 发现一堆 Sorting result → 查 Created_tmp_disk_tables 确认临时表落盘 → 翻慢查询日志定位具体 SQL → EXPLAIN 发现缺失索引。漏掉任一环，监控就只剩数字，没有诊断价值。
