MySQL 实时监控用 SHOW STATUS
和 SHOW PROCESSLIST
就够用，但得会筛关键指标
不用一上来就上 Grafana + Prometheus，很多运维问题靠 MySQL 自带命令 30 秒内就能定位。关键是知道看什么、不看什么。
SHOW STATUS返回几百个变量，真正要盯的其实就几个：
Threads_connected（当前连接数）、
Threads_running（活跃线程）、
Queries（总查询量）、
Slow_queries（慢查询计数）、
Key_reads/
Key_read_requests（缓存命中率相关）。
SHOW PROCESSLIST重点不是看“有没有长连接”，而是找
State为
Sending data、
Copying to tmp table、
Locked的线程——这些才是真卡点。 用
SHOW FULL PROCESSLIST避免 SQL 被截断 加
WHERE Command != 'Sleep'过滤掉无效连接 配合
SELECT TIME, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE TIME > 60快速揪出执行超 1 分钟的语句
轻量级长期监控首选 mytop
，比 mysqladmin
直观得多
mytop是 Perl 写的终端工具，不依赖外部服务，装完就能跑，适合快速巡检或低配服务器。
它把
SHOW STATUS和
SHOW PROCESSLIST的核心字段做了聚合展示：实时 QPS、每秒慢查、连接数趋势、Top SQL 排序。比反复敲命令省事，又不像 Zabbix 那样要配 agent 和 server。 安装：
sudo apt install mytop（Debian/Ubuntu）或
cpan App::mytop启动时必须指定用户：
mytop -u root -p --prompt，否则连不上（默认不读
~/.my.cnf） 按
t切换排序字段，
q退出；注意它默认刷新间隔是 5 秒，太频繁可能加重负载
生产环境别只靠脚本轮询 INFORMATION_SCHEMA
，小心锁表和性能抖动
很多人写 Python 或 Shell 脚本定时查
INFORMATION_SCHEMA.PROCESSLIST或
TABLES，但没意识到：在高并发下，这类查询本身会持有 MDL 锁，尤其当表多、分区多时，可能阻塞 DDL，甚至拖慢业务查询。
更稳的做法是走 Performance Schema（MySQL 5.6+ 默认开启），它用内存引擎采集，几乎无锁：
查当前等待事件：SELECT EVENT_NAME, COUNT_STAR FROM performance_schema.events_waits_summary_global_by_event_name WHERE COUNT_STAR > 0 ORDER BY COUNT_STAR DESC LIMIT 10查热点表 IO：
SELECT OBJECT_NAME, COUNT_READ, SUM_NUMBER_OF_BYTES_READ FROM performance_schema.table_io_waits_summary_by_table ORDER BY SUM_NUMBER_OF_BYTES_READ DESC LIMIT 5记得先确认是否启用：
SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'events_waits%';，没开的话要 SET 启用
Python 运维脚本推荐 mysql-connector-python
而非 PyMySQL
，尤其涉及大结果集
两者都能连 MySQL，但底层差异影响稳定性：
mysql-connector-python是 Oracle 官方维护，对连接池、SSL、压缩协议支持更完整；
PyMySQL纯 Python 实现，在处理百万行结果集时容易 OOM 或超时。
比如做自动慢日志分析，用
mysql-connector-python可以安全启用地流式游标（
cursor = cnx.cursor(buffered=False)），边取边处理，内存占用恒定。
import mysql.connector
cnx = mysql.connector.connect(
host='localhost',
user='monitor',
password='xxx',
database='information_schema',
connection_timeout=10,
autocommit=True
)
cursor = cnx.cursor(buffered=False) # 关键：禁用缓冲，防内存爆炸
cursor.execute("SELECT * FROM PROCESSLIST WHERE TIME > 30")
for row in cursor:
print(row[0], row[3], row[6]) # ID, User, Time
cursor.close()
cnx.close()用
PyMySQL做同样事，得手动分页或加
fetchmany(1000)，稍不注意就卡死。
真正难的不是选哪个工具，而是定义清楚“我要监控什么”——是查连接泄漏？还是定位某次延迟突增？还是长期容量趋势？同一个工具，目标不同，配置和解读方式就完全不同。别让监控变成另一个黑盒。
