一、数据库监控就像汽车的仪表盘

想象一下驾驶没有仪表盘的汽车：你无法知晓油量还剩多少、发动机是否过热、刹车系统是否正常。MySQL的各项监控指标就是数据库的「生命体征仪」，比如：

-- 查看当前活跃连接数（示例技术栈：MySQL 8.0）
SHOW STATUS WHERE Variable_name = 'Threads_connected';

-- 系统变量查看最大连接数限制
SHOW VARIABLES LIKE 'max_connections';

这类查询就像观测发动机转速，当Threads_connected长期接近max_connections时，就像水温表飙红，提示可能遭遇拒绝服务（Too many connections）风险。

二、你必须关注的四大核心指标

2.1 连接池指标：数据库的"咽喉要道"

示例：通过系统视图实时观测连接状态

-- 查看各状态连接明细（MySQL 8.0+）
SELECT user, 
       command,
       COUNT(*) AS cnt 
FROM information_schema.processlist 
GROUP BY user, command 
ORDER BY cnt DESC;

/* 注释：
user列显示使用者身份（应用账号/系统进程）
command列展示执行状态（Sleep/Query/Send data等）
当Sleep状态占比超过50%需排查连接池配置合理性 */

2.2 慢查询分析：找出拖后腿的元凶

示例：通过EXPLAIN诊断问题查询

-- 慢查询日志配置（需在my.cnf中添加）
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1 

-- 使用EXPLAIN分析查询路径（示例技术栈：InnoDB引擎）
EXPLAIN SELECT * 
FROM orders 
WHERE create_time > '2023-01-01' 
  AND status = 'pending' 
ORDER BY total_amount DESC;

/* 执行计划关键解读：
type=ALL 表示全表扫描
rows=50000 显示预估扫描行数
Extra=Using filesort 揭示未使用合适索引排序 */

2.3 锁等待监控：化解数据争夺战

示例：检测当前锁阻塞情况

-- 查看等待锁的事务（MySQL 8.0）
SELECT * 
FROM performance_schema.data_lock_waits;

-- 诊断具体阻塞源
SELECT r.trx_id blocking_trx_id,
       r.trx_mysql_thread_id blocking_thread,
       b.requesting_trx_id waiting_trx_id,
       b.requesting_pid waiting_pid
FROM information_schema.innodb_lock_waits b
JOIN information_schema.innodb_trx r 
  ON r.trx_id = b.blocking_trx_id;

/* 注释：
当出现大量lock_mode=X等待时
应考虑调整事务隔离级别或优化SQL执行顺序 */

2.4 缓冲池使用率：数据库的"记忆宫殿"

示例：查看缓冲池运行状态

-- 缓冲池关键指标查询
SELECT * 
FROM information_schema.INNODB_BUFFER_POOL_STATS;

-- 计算命中率公式（需定期采集计算）
（1 - (innodb_buffer_pool_reads / innodb_buffer_pool_read_requests)) * 100 

/* 理想命中率应维持在98%以上
当数值持续低于90%时需考虑扩展内存容量
或检查是否存在全表扫描等异常操作 */

三、专业巡检工具箱

3.1 pt-query-digest手术刀

# 分析慢查询日志（示例技术栈：Percona Toolkit）
pt-query-digest /var/log/mysql/slow.log 

/* 输出报告包含：
Query_time_distribution: 查询时间分布情况
Tables_affected: 涉及的数据表
Lock_time_analysis: 资源争用情况 */

3.2 Prometheus+Grafana可视化系统

# Prometheus配置示例（监控项片段）
- job_name: 'mysql'
  static_configs:
  - targets: ['dbserver:9104']
  params:
    collect[]:
      - global_status
      - innodb_metrics
      - perf_schema.file_events

四、典型案例会诊室

4.1 促销期间数据库响应延迟

现象：QPS突增时TPS下降，慢查询日志无异常。
破解：通过SHOW ENGINE INNODB STATUS观察到大量RECORD LOCKS，调整批量更新策略后锁争用减少60%。

4.2 凌晨ETL任务卡顿

现象：定时任务频繁超时，硬盘IO指标显示长期100%使用率。
解决方案：优化全表更新为分批处理，innodb_flush_log_at_trx_commit参数从1调整为2。

五、监控体系的双刃剑特性

优势面：

  • 提前预警临界状态（如磁盘容量、连接数）
  • 历史数据对比发现异常波动
  • 性能瓶颈精准定位（CPU/内存/IO）

挑战点：

  • 指标阈值需动态调整（业务高峰期与日常差异）
  • 过多的监控项可能掩盖真正问题
  • 历史数据存储成本随精度提升指数级增长

六、专家建议备忘录

  1. 建立基准参照系：记录业务正常时期的指标均值
  2. 日志轮转要科学：慢查询日志保留周期建议7-15天
  3. 容器化环境关注点：网络延迟对监控数据的影响
  4. 指标关联分析原则：如高CPU使用率需同步检查缓存命中率
  5. 云数据库需注意：部分原生指标可能被云平台隐藏