监控体系：INNODB STATUS 与 Performance Schema

告警只盯 Threads_running 时，真正的问题可能是 history list length 暴涨（purge 滞后）或 log mutex 等待——它们在 SHOW ENGINE INNODB STATUS 里有专门段落，却不在 SHOW GLOBAL STATUS 顶层。MySQL 8.0 的 Performance Schema 把锁、事务、内存分配细到线程级；配合 Prometheus mysqld_exporter 才能做 SLO。

本文对照 PG 监控篇，版本 8.0.36。

一、监控分层

flowchart TB
  APP[应用 SLA] --> EXP[mysqld_exporter]
  EXP --> GSV[GLOBAL STATUS]
  EXP --> PFS[performance_schema]
  DBA[应急排查] --> STATUS[SHOW ENGINE INNODB STATUS]
  PFS --> LOCKS[data_locks]
  PFS --> TRX[events_transactions_*]

二、INNODB STATUS 精读段落

SHOW ENGINE INNODB STATUS\G

History list length（HLL）：未 purge 的 undo 量——第 17 篇 长事务核心信号。

三、Performance Schema 关键表

-- 需本地验证
SELECT * FROM performance_schema.data_locks LIMIT 5;
SELECT * FROM performance_schema.data_lock_waits LIMIT 5;
SELECT * FROM performance_schema.events_transactions_current LIMIT 5;

启用：performance_schema=ON（8.0 默认）；部分 consumer 需 setup_consumers 打开。

四、mysqld_exporter 指标映射

与应用 p99 延迟 同屏，避免只看平均 STATUS。

五、实验（需本地验证）

定期抓取 STATUS 与 PFS 基线；故障时对比 SEMAPHORES 与 TRANSACTIONS 段差分。

六、关键要点

1. INNODB STATUS 适合应急快照；PFS 适合关联线程。
2. HLL 是 purge 滞后的一号信号。
3. 死锁段 只保留最近一次——需持续采集若要做趋势。
4. exporter 指标需与 STATUS 交叉验证口径。

十、PG 对照

PG 第 21 篇 强调 分层视图；InnoDB 传统 STATUS 是单页快照，应用 PFS 补齐时序维度。

上一篇：Change Buffer 与 AHI

下一篇：经典故障模式

参考资料

源码（MySQL 8.0.36）

• storage/innobase/ — 引擎实现
• sql/binlog.cc, sql/handler.cc — Server 层交界

官方文档

• MySQL 8.0 Reference Manual, InnoDB / Replication / Backup

相关文章

• 系列索引
• PostgreSQL 内核系列