一、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_completeIO完成处理或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/mem0memInnoDB内部堆以及临时表内存。此外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手动采集零散指标难以形成趋势生产环境强烈建议搭建时序监控。经典组合mysqld_exporterPrometheus官方出口暴露数百个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。node_exporter采集操作系统CPU、内存、磁盘等指标如node_cpu_seconds_total、node_memory_MemAvailable_bytes。Grafana仪表板使用社区模板如Percona的MySQL Overview聚合展示。核心告警规则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%时即触发分析而非等到告警阈值。
