MySQL数据库CPU与内存监控全攻略：从系统到内核的立体化观测体系

文章MySQL数据库CPU与内存监控全攻略：从系统到内核的立体化观测体系分享给大家，欢迎收藏极客资料网，专注分享技术知识

引言：无监控，不运维

在关键信息基础设施安全保障体系中，实时、精准的资源监控是发现性能瓶颈、预防故障的第一道防线。MySQL数据库作为业务数据的承载核心，其CPU和内存的消耗直接决定了服务的吞吐量与稳定性。很多性能故障（如上一篇文章分析的CPU间歇性飙高）若能被及时监控和预警，就完全可以在恶化前被扼杀在摇篮里。本文将系统梳理从操作系统到数据库内核的多层次CPU与内存监控方法，并提供可落地的监控指标与脚本，帮助您构建起全天候的数据库资源感知能力。

---

一、CPU使用率监控：揪出消耗源的“三层雷达”

CPU是数据库的算力根本，监控CPU的核心目标是快速识别：是MySQL进程整体吃满CPU，还是某些线程异常导致？是用户SQL消耗，还是后台任务引发？

1. 操作系统层：进程与线程级快照

• 全局视图：top -c（或htop），关注 %Cpu(s) 整体使用率、mysqld 进程的 %CPU 及 load average。
• 进程精准跟踪：pidstat -p <mysqld_pid> 1，按秒刷新进程的CPU占用、上下文切换等。
• 线程级解剖：top -H -p <mysqld_pid>，找出MySQL内部哪个线程在大量消耗CPU。结合 performance_schema.threads 表，通过 THREAD_OS_ID 反查该线程是用户连接还是后台线程。
• 函数级热点（优化利器）：perf top -p <mysqld_pid>，实时显示进程内部函数调用开销。当CPU飙升却无慢查询时，可快速发现是ut_delay（锁自旋）、buf_page_io_complete（IO完成处理）或LRU相关函数在消耗CPU。

2. MySQL全局状态：宏观计数器

借助 SHOW GLOBAL STATUS 提取反映CPU压力的核心指标：

-- 每秒查询量（大体反映CPU活跃度）
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Uptime';
-- 计算 Questions / Uptime 得到每秒平均查询数

-- 当前活跃线程数（是否是连接风暴）
SHOW GLOBAL STATUS LIKE 'Threads_running';

-- InnoDB行操作量（内部CPU开销）
SHOW GLOBAL STATUS LIKE 'Innodb_rows_read';
SHOW GLOBAL STATUS LIKE 'Innodb_rows_updated';

将这些指标用Prometheus等时序库收集，可绘制QPS、Threads_running趋势图，CPU飙升通常伴随着它们的突增。

3. Performance Schema：线程级别的CPU消费

MySQL 8.0的performance_schema已能直接记录线程的CPU时间（需开启相关instrument）：

-- 查看当前执行的SQL及其累计CPU时间（需要在setup_consumers中启用events_statements_current等）
SELECT 
  t.THREAD_ID, 
  t.PROCESSLIST_ID, 
  t.PROCESSLIST_USER,
  t.PROCESSLIST_INFO,
  st.SUM_TIMER_WAIT / 1000000000000 AS cpu_seconds
FROM performance_schema.events_statements_current st
JOIN performance_schema.threads t ON st.THREAD_ID = t.THREAD_ID
WHERE t.TYPE = 'FOREGROUND' 
ORDER BY cpu_seconds DESC;

更常用的监控视图sys.statement_analysis和sys.user_summary均基于这些数据，展示按总耗时排序的SQL，直接指向CPU消耗大户。

实战建议：将Threads_running阈值告警设为CPU核数的2倍，配合perf top或sys.statement_analysis，可在5分钟内定位绝大多数CPU问题。

---

二、内存使用率监控：认清“分配”与“实际占用”

MySQL的内存结构复杂，分为全局共享内存（如innodb_buffer_pool）和会话私有内存（如排序缓冲、连接缓冲）。监控时必须区分操作系统看到的物理内存占用（RSS）与MySQL内部已分配但未使用的内存，避免OOM风险。

1. 操作系统层：看“实际消耗”

• 基础命令：ps aux | grep mysqld 查看 RSS（常驻内存集），free -h 看系统整体内存。
• 更精准：smem -t -p mysqld 可分析PSS（比例分摊共享内存），避免共享库重复计算。
• 内存压力：cat /proc/meminfo 关注 MemAvailable，配合 dmesg | grep -i oom 监控OOM Killer活动。

2. MySQL内存组成的理论计算

运维中常通过以下公式估算MySQL最大可能内存使用量：

总内存 ≈ innodb_buffer_pool_size 
        + key_buffer_size 
        + query_cache_size (8.0已移除)
        + max_connections × (sort_buffer_size + read_buffer_size + join_buffer_size + binlog_cache_size + thread_stack + 临时表开销)
        + 其他(performance_schema, AHI等)

查询配置：

SELECT 
  @@innodb_buffer_pool_size/1024/1024 AS buffer_pool_MB,
  @@key_buffer_size/1024/1024 AS key_buffer_MB,
  @@max_connections,
  @@sort_buffer_size/1024 AS sort_buffer_KB,
  @@read_buffer_size/1024 AS read_buffer_KB,
  @@join_buffer_size/1024 AS join_buffer_KB,
  @@thread_stack/1024 AS thread_stack_KB;

关键点：会话级缓冲虽按需分配，但若max_connections过大，峰值内存可能远超物理内存。此为常见的配置陷阱。

3. Performance Schema 内存监控（8.0重磅功能）

MySQL 8.0内置了详细的内存使用统计，通过memory_summary系列表可查看各类内存分配的明细：

-- 按内存事件类型查看总计分配与释放
SELECT
  EVENT_NAME,
  CURRENT_NUMBER_OF_BYTES_USED / 1024 / 1024 AS currently_used_MB,
  HIGH_NUMBER_OF_BYTES_USED / 1024 / 1024 AS high_used_MB
FROM performance_schema.memory_summary_global_by_event_name
WHERE CURRENT_NUMBER_OF_BYTES_USED > 0
ORDER BY CURRENT_NUMBER_OF_BYTES_USED DESC
LIMIT 10;

常见内存大户：memory/innodb/buf_buf_pool（缓冲池）、memory/sql/TABLE（表缓存）、memory/innodb/mem0mem（InnoDB内部堆），以及临时表内存。

此外，sys.memory_global_total 和 sys.memory_by_user_by_current_bytes 视图提供了更直观的汇总。

4. InnoDB缓冲池内存使用细节

缓冲池是内存的头号消费者，需监控其内部利用率和命中率：

-- 缓冲池大小与使用量
SHOW STATUS LIKE 'Innodb_buffer_pool_pages_total';
SHOW STATUS LIKE 'Innodb_buffer_pool_pages_free';
-- 命中率（如前文公式）

结合 innodb_buffer_pool_size 设置，可评估是否存在浪费或不足。

---

三、构建一体化监控体系（Prometheus + Grafana）

手动采集零散指标难以形成趋势，生产环境强烈建议搭建时序监控。经典组合：

1. mysqld_exporter：Prometheus官方出口，暴露数百个MySQL指标，包括上面提到的mysql_global_status_threads_running、mysql_global_variables_innodb_buffer_pool_size、mysql_global_status_innodb_buffer_pool_read_requests等。CPU相关指标可利用mysql_global_status_questions推算QPS。
2. node_exporter：采集操作系统CPU、内存、磁盘等指标，如node_cpu_seconds_total、node_memory_MemAvailable_bytes。
3. Grafana仪表板：使用社区模板（如Percona的MySQL Overview），聚合展示。
4. 核心告警规则：
   • CPU使用率：node_cpu_utilisation > 80% 持续5分钟。
   • 内存可用：node_memory_MemAvailable_bytes < 物理内存的10%。
   • MySQL缓冲池命中率：(1 - (rate(mysql_global_status_innodb_buffer_pool_reads[5m]) / rate(mysql_global_status_innodb_buffer_pool_read_requests[5m]))) * 100 < 99%。
   • 运行线程数：mysql_global_status_threads_running > 核数×2。

---

四、监控实践要诀：从“看得见”到“看得懂”

• CPU监控：优先关注 Threads_running 和活跃SQL的CPU累计消耗，再结合操作系统线程分析，区分“计算密集”和“锁/IO等待导致的内核态开销”。
• 内存监控：避免只看RSS，需结合Performance Schema的内存总量统计，并定期扫描 memory_summary_global_by_event_name 中的 HIGH_NUMBER_OF_BYTES_USED，防止内存泄漏。
• 基线建立：将平稳运行时段的CPU使用率、内存占用量、缓冲池命中率等作为基线，当偏差超过20%时即触发分析，而非等到告警阈值。

结语：完善的监控体系是数据库运维从“被动救火”走向“主动治理”的分水岭。通过操作系统、MySQL全局状态、Performance Schema的三层联防，CPU和内存的每一次微小抖动都能被捕捉、溯源，最终在影响业务之前得到化解。让数据开口说话，让故障止步于萌芽——这才是数字时代数据库管理的正确姿态。

文章来源:https://www.cnblogs.com/liuziyi1/p/20418235
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！