应重点关注Threads_connected、Threads_running、Questions、Key_reads/Key_read_requests比值（仅MyISAM）、Created_tmp_tables与Created_tmp_disk_tables比率，并谨慎使用PROCESSLIST查询关键字段过滤长事务。
怎么从 SHOW STATUS 里挑出真正有用的监控指标
不是所有 SHOW STATUS 返回的 400+ 项都值得监控。多数是内部计数器，波动大、无业务含义，还容易误报。重点关注那些能反映连接压力、查询瓶颈、缓存效率的指标。
实操建议：
-
Threads_connected和Threads_running必须监控：前者超限说明连接池配置不合理或应用没正确释放连接；后者持续 > 20 常意味着慢查询堆积 -
Queries和Questions区别清楚：Queries包含所有解析过的语句（含子查询），Questions只算客户端发起的请求——做 QPS 统计用Questions更准 -
Key_reads/Key_read_requests比值 > 0.01 表示 MyISAM 键缓存命中率差；但如果是 InnoDB 引擎，这个比值完全不用看 - 避免监控
Created_tmp_disk_tables单独数值——它只在查询执行时临时生成，必须结合Created_tmp_tables算比率才有意义
用 information_schema.PROCESSLIST 抓实时长事务，但别直接轮询
查 PROCESSLIST 是发现卡住的事务最直接的方式，但频繁 SELECT * FROM information_schema.PROCESSLIST 会锁元数据表，在高并发下反而拖慢 MySQL。
实操建议：
- 只查关键字段：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE TIME > 60，过滤掉TIME 的常规连接 - 加
WHERE COMMAND != 'Sleep'，避免被大量空闲连接干扰 - 不要用
INFORMATION_SCHEMA做聚合统计（比如 count(*) over time），它的性能开销不稳定；改用performance_schema.threads+events_statements_current（需提前开启对应 consumer） - 如果只是想告警，用
mysqladmin processlist命令配合grep -E 'Query.*[0-9]{3,}'更轻量，不走 SQL 解析路径
SHOW GLOBAL VARIABLES 里哪些配置变动必须立刻告警
有些变量改了不重启就生效，但会影响稳定性。监控它们不是为了“知道变了”，而是防止人误操作或自动化脚本失控。
实操建议：
- 必须盯紧：
max_connections（调低可能触发连接拒绝）、innodb_buffer_pool_size（动态调整有内存碎片风险，且仅部分版本支持）、wait_timeout（设太小会让应用连接频繁断开） -
sql_mode变更要警惕：比如从宽松模式切到严格模式（STRICT_TRANS_TABLES），可能让原本能插入的数据报错 - 别监控
version或hostname——这些静态值变化只发生在重启或机器变更时，不属于运行时风险点 - 采集频率建议 5 分钟一次即可，高频轮询
SHOW VARIABLES对性能无益，反而增加网络和解析开销
为什么用 performance_schema 采集指标反而更稳，但默认关着
MySQL 5.6+ 默认关闭 performance_schema，不是因为它没用，而是它开启后有约 5% 性能损耗——但这个代价换来的指标粒度和稳定性，远超 SHOW STATUS。
实操建议：
- 至少启用：
events_statements_summary_by_digest（看慢查询指纹）、table_io_waits_summary_by_table（定位热点表）、memory_summary_global_by_event_name（查内存泄漏嫌疑） - 禁用高开销项：
events_stages*和events_waits*（除非真在做深度性能分析），它们会让performance_schema内存占用翻倍 - 注意
setup_consumers表里的开关：比如events_statements_current开着但events_statements_history_long关着，才能兼顾实时性和内存控制 - 用
SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 5替代慢日志分析，响应更快，还不依赖磁盘 I/O
最常被忽略的是指标上下文：同一个 Threads_running 值，在读多写少的报表库可能是异常，在写密集的订单库可能只是常态。监控不能脱离业务场景定阈值。
