监控mysql核心是盯住连接数、吞吐量、缓存效率、阻塞与慢查询四大维度：threads_connected和threads_running反映连接压力，qps/tps体现业务负载，innodb缓冲池命中率需＞95%，show processlist和慢日志配合explain定位性能瓶颈。
监控 MySQL 数据库运行状态，核心是盯住几个关键指标，并用对工具——不是堆监控系统就行，而是让数据真正反映数据库“有没有喘得过来气”。下面从实操角度分四块说清楚。
连接数与线程状态
连接资源是最先耗尽的瓶颈。重点关注两个值：
-
Threads_connected：当前活跃连接数，用
SHOW GLOBAL STATUS LIKE 'Threads_connected';查； - Threads_running：正在执行查询的线程数，它比总连接数更能反映瞬时压力。
同时查配置：SHOW VARIABLES LIKE 'max_connections';。如果 Threads_connected 长期超过 max_connections 的 80%，说明连接池快满了，可能引发拒绝连接或超时。还要留意 Aborted_connects 和 Aborted_clients 是否异常上升，这往往指向认证失败、网络中断或客户端未正常断开。
查询吞吐量与事务速率
QPS（每秒查询数）和 TPS（每秒事务数）是业务负载的直接体现：
-
QPS =
Questions÷Uptime（SHOW GLOBAL STATUS LIKE 'Questions';和Uptime）； -
TPS = (
Com_commit+Com_rollback) ÷Uptime。
注意：Questions 统计客户端发来的语句，不含存储过程内部执行；而 Queries 包含所有 SQL 执行次数。两者差异能帮你判断是否大量逻辑在存储过程中执行。突增的 QPS/TPS 要结合 Threads_running 和慢查询日志一起看，避免误判为“高并发”实则是“低效查询堆积”。
缓存效率与 I/O 压力
缓存命中率低，等于反复读盘，性能必然下滑：
-
InnoDB 缓冲池命中率：计算公式为
(1 - Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests) × 100%，目标应 >95%； -
MyISAM 键缓存命中率（如仍在用）：
(1 - Key_reads / Key_read_requests) × 100%； - 额外关注
Bytes_received和Bytes_sent，它们反映网络吞吐，突增可能意味着大结果集或不当查询。
如果 Innodb_buffer_pool_reads 持续升高，优先检查 innodb_buffer_pool_size 是否设置过小，而不是立刻优化 SQL——内存不够，再好的索引也救不了。
阻塞、慢查询与复制状态
这是问题定位的“现场勘查”环节：
-
SHOW PROCESSLIST\G或SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST;，重点看State和Time列，识别Sending data、Locked、Copying to tmp table等高危状态； - 开启慢查询日志（
slow_query_log = ON，long_query_time = 1），定期用mysqldumpslow或分析工具提取 TOP SQL，再用EXPLAIN看执行计划； - 主从复制监控：在从库执行
SHOW SLAVE STATUS\G，紧盯Seconds_Behind_Master、Slave_IO_Running和Slave_SQL_Running三项，任一为No即告警。
临时表和排序操作也藏风险：Created_tmp_tables、Created_tmp_disk_tables、Sort_merge_passes 这些指标持续走高，说明查询缺乏合适索引或 sort_buffer_size 设置不合理。
