数据库监控指标覆盖哪些？，连接数CPU慢查询怎么监控

监控数据库健康，盯紧连接数、CPU使用率和慢查询日志这三项指标，就能快速定位绝大多数性能瓶颈。

数据库运维中，连接数、CPU与慢查询是衡量健康状态的三个核心维度，它们直接反映数据库的负载压力、资源消耗和查询效率，是日常监控的基石，行业共识认为，这三项指标覆盖了数据库外部连接、内部资源与执行质量的全链路,任何一项出现异常都意味着需要立即介入。

数据库监控指标有哪些？连接数、CPU与慢查询是核心

数据库健康不能只看表面，需要从连接承载、资源占用和查询效率三个层面切入，连接数反映数据库的并发承受能力，CPU使用率体现计算资源紧张程度，慢查询日志则暴露查询设计的短板，三者相互影响：连接数过高会推高CPU消耗，慢查询增多会拖慢整体响应,最终导致连接堆积。

连接数：数据库的排队窗口

连接数代表当前与数据库建立的会话数量，每个连接都会占用内存和线程资源，超过设定上限后，新连接会被拒绝，监控连接数不仅看总量，还要看活跃连接数与空闲连接数的比例，活跃连接数过高意味着查询压力大,空闲连接数过多则浪费资源。

CPU使用率：计算资源的晴雨表

CPU使用率直接反映数据库的运算压力，正常情况下，CPU使用率会随业务请求波动，但持续高于某个阈值（如80%以上）往往意味着存在低效查询或锁竞争，CPU飙升的常见来源包括：大量全表扫描、排序操作、临时表创建,以及频繁的索引更新。

慢查询日志：查询效率的照妖镜

慢查询日志记录执行时间超过指定阈值的SQL语句，通过分析慢查询，可以定位索引缺失、表结构不合理或查询写法不当的问题，慢查询不仅是性能隐患,还可能在流量高峰期拖垮整个数据库。

连接数过高怎么办？从监控到优化

连接数过高是数据库运维中最常见的报警之一，当业务突发流量增加或应用程序未正确释放连接时，连接数会迅速攀升,导致数据库响应变慢甚至拒绝服务。

监控连接数的具体操作

• 查看当前连接数：在MySQL中执行 SHOW STATUS LIKE 'Threads_connected',获取当前建立的连接总数。
• 查看活跃连接数：执行 SHOW STATUS LIKE 'Threads_running',得到正在执行查询的线程数。
• 对比最大连接数：执行 SHOW VARIABLES LIKE 'max_connections'，了解系统允许的最大连接数，当当前连接数接近最大值的80%时,就需要警惕。

连接数过高的排查步骤

1. 检查应用程序连接池配置，确保连接池大小合理,且有空闲回收机制。
2. 使用 SHOW PROCESSLIST 查看哪些连接是长时间空闲或处于“Sleep”状态,并定位来源IP和用户。
3. 对于短时间内连接数暴增的情况,检查是否有异常访问或重复连接请求。

如何调整连接数上限

直接增大 max_connections 并非长久之计，因为每个连接会消耗内存，一个连接默认占用约4MB内存，当连接数从200增加到500时，内存占用量会显著上升,调优策略包括：

• 设置合理的连接池大小，推荐公式为 (核心线程数 2 + 有效磁盘数)。
• 使用连接池中间件（如HikariCP、Druid）统一管理连接。
• 在数据库上设置 max_execution_time 限制查询超时,防止慢查询长时间占用连接。

数据库CPU飙升如何排查？定位与解决方案

CPU使用率飙升通常意味着数据库在执行大量计算密集型操作，业内专家指出，CPU飙升与查询效率低下直接相关,排查重点在于找出消耗CPU的查询。

实时定位CPU消耗源

• 系统层面：使用 top -H 查看MySQL进程的线程CPU占用,找到高消耗的线程ID。
• 数据库层面：在MySQL中执行 SHOW PROCESSLIST 查看正在执行的查询，重点关注 State 列显示为 Sending data、Sorting result 或 Creating tmp table 的会话。
• 性能模式：开启 performance_schema 后，查询 events_statements_current 表，按 CPU_TIME 排序,直接定位高消耗SQL。

常见CPU飙升成因与对应操作

• 全表扫描：查询未使用索引，导致数据库逐行检查，通过 EXPLAIN 分析执行计划,补全缺失索引。
• 大量排序操作：ORDER BY 或 GROUP BY 字段未索引，导致使用文件排序，为排序字段添加索引，或调整 sort_buffer_size。
• 临时表创建：复杂查询生成临时表，增加CPU和内存开销，优化查询逻辑,避免子查询嵌套。
• 锁冲突：行锁等待导致线程反复重试，使用 SHOW ENGINE INNODB STATUS 查看锁信息,缩短事务执行时间。

降低CPU负载的长期策略

• 定期审计慢查询,将查询优化纳入日常开发流程。
• 对高频查询引入缓存层（如Redis）,减少对数据库的直接请求。
• 在业务低峰期执行批量操作和大表维护,避免与高峰期叠加。

慢查询日志分析：优化查询性能的关键

慢查询日志是数据库调优的第一手资料，通过分析慢查询，可以找到执行效率低下的SQL，从而进行针对性优化，多数情况下,慢查询的根因是索引缺失或查询写法不当。

开启与配置慢查询日志

• 在MySQL配置文件（my.cnf）中设置：

  slow_query_log = ON
  slow_query_log_file = /var/log/mysql/slow.log
  long_query_time = 2
  log_queries_not_using_indexes = ON

  long_query_time 建议设为1-2秒，过短会生成大量日志影响性能,过长则可能遗漏问题。

• 动态开启：执行 SET GLOBAL slow_query_log = ON;,无需重启。

使用工具分析慢查询日志

• mysqldumpslow：MySQL自带工具，支持按查询次数、锁等待时间、返回行数等维度汇总，常用命令：

  mysqldumpslow -s c -t 10 slow.log

  按查询次数排序,列出前10条。

• pt-query-digest：Percona Toolkit里的分析工具，输出更详细，支持按总体时间、执行次数排序，会生成每条查询的执行频率、平均时间、响应时间分布等。

优化慢查询的实操步骤

1. 用 EXPLAIN 分析执行计划，关注 type、rows、Extra 等字段。
2. type = ALL 表示全表扫描,需要添加索引。
3. 对于 Extra 包含 Using filesort 或 Using temporary 的查询,调整索引顺序或查询结构。
4. 对于大表，考虑分页优化,使用延迟关联或覆盖索引减少回表次数。
5. 定期归档和清理历史数据,避免表数据量过大影响查询性能。

综合监控方案：守护数据库健康

将连接数、CPU和慢查询融合到一个统一的监控体系中，可以实现主动预警和快速响应,推荐使用开源工具组合搭建监控平台。

监控指标与告警阈值设计

搭建监控平台的操作路径

• 数据采集：使用Prometheus + MySQL Exporter，定期采集连接数、CPU、慢查询等指标。
• 可视化：Grafana导入预置的MySQL仪表盘,实时展示趋势图。
• 告警通知：在Grafana或Alertmanager中配置规则，通过钉钉、邮件或企业微信推送。
• 日志集中：使用ELK（Elasticsearch、Logstash、Kibana）收集慢查询日志,支持全文搜索与聚合分析。

运维检查清单

• 每天检查一次连接数最高峰和CPU使用率曲线。
• 每周汇总一次慢查询日志，推动开发团队优化Top 10查询。
• 每月评估一次监控阈值是否合理,根据业务变化调整。

Q&A：数据库监控指标常见问题

问题1：数据库连接数设置多少合适？

连接数上限应根据服务器内存和核数合理设置，一个连接约占用2-4MB内存，假设服务器有32GB内存预留20GB给数据库，建议连接数不超过5000，同时要结合应用连接池设置，连接池大小通常为单机核心线程数的2倍左右,避免连接数超过数据库上限。

问题2：CPU使用率一直很高，但找不到慢查询怎么办？

检查是否存在大量短连接频繁建立和销毁，这种场景下单条查询并不慢，但集中在一起会消耗CPU，可以通过 SHOW STATUS LIKE 'Connections' 观察每秒新建连接数，如果超过数百，建议使用连接池复用连接，检查是否有锁等待导致线程重试,或是否存在大量写入操作频繁刷新日志。

问题3：慢查询日志会影响数据库性能吗？

开启慢查询日志本身对性能影响极小，但日志文件写入量较大时可能占用磁盘IO，建议将 long_query_time 设置到合理阈值（如1-2秒），并开启日志引擎的内存缓冲，生产环境中，将慢查询日志输出到独立磁盘，或通过远程日志服务收集，可避免对数据库IO造成影响，慢查询日志是排查问题的第一手资料,一笔宝贵的数据资产。

连接数、CPU和慢查询三个维度，构成了数据库健康的完整三角，日常监控中紧盯这三项，配合定期分析和优化，能有效预防多数性能问题，维护好这三个指标,数据库稳定运行就有了可靠保障。