数据库健康监控指标有哪些？连接数、CPU与慢查询如何监测，数据库性能优化必看

数据库健康监控的核心指标，就是连接数、CPU使用率和慢查询这三项。 连接数直接反映并发压力，CPU使用率体现数据库整体负载，慢查询则暴露SQL质量与索引问题，把这三个维度盯住，就能覆盖绝大多数数据库健康风险。

数据库监控指标有哪些？连接数与CPU使用率优先盯

数据库监控指标有很多,但真正需要长期跟踪的，其实就围绕资源、连接和SQL质量展开，行业共识认为，连接数和CPU使用率是最容易先出问题的两个指标，慢查询则是性能劣化的导火索。

连接数：数据库的“在线人数”

连接数可以理解为数据库同时在服务的会话数量,每个连接都要占用内存和CPU上下文，连接数过高时，数据库会拒绝新请求，甚至触发OOM，常见的连接满错误类似“Too many connections”，通常不是瞬间爆发，而是逐渐累积。

观察连接数不能只看总数,要关注活跃连接数和空闲连接数的比值，如果空闲连接占了大部分，问题往往出在应用连接池配置上；如果活跃连接持续偏高，才是真正的查询压力大。

常用命令：

• show status like 'Threads_connected'; 查看当前总连接数
• show processlist; 查看每个会话在做什么
• show variables like 'max_connections'; 确认上限

CPU使用率：数据库的“心跳频率”

CPU使用率过高,意味着数据库在大量做计算、排序或锁等待，MySQL的CPU飙升，通常有四种来源：慢查询、全表扫描、连接风暴、并发大事务，其中慢查询和全表扫描是根源。

判断CPU是否异常,不能只看瞬时值，要看趋势，如果CPU长期在80%以上，且伴随连接数同步爬升，基本可以判定为负载型问题，如果CPU突然打满，但连接数正常，大概率是某条SQL在作怪。

建议采集：

• top -u mysql 查看mysql进程CPU占比
• vmstat 1 观察用户态和内核态CPU分布



• 搭配pt-query-digest或performance_schema分析SQL耗时

数据库连接数过高怎么办？先分清“真满”和“假满”

很多运维朋友一看到连接数报警,就急着调max_connections，业内专家指出，调大上限只是缓兵之计，不排查根因，只会让数据库在崩溃边缘多撑一会儿，连接数过高的处理，需要区分两种情况。

连接数缓慢爬升，持续接近上限

这种情况多与应用侧连接池配置有关,比如连接池maxActive设置过大，或者连接泄漏，每次请求都创建新连接却忘了回收，表现为数据库端Threads_connected只增不减，但Threads_running很低。

操作步骤：

1. 先查show status like 'Threads_running';确认活跃线程数。
2. 如果运行数小,总连接高，拿performance_schema.threads视图看各个连接来源。
3. 回应用侧检查连接池参数：初始连接数、最大连接数、空闲超时时间。
4. 给连接池增加validationQuery，避免把失效连接发给数据库。

连接数瞬间打满，CPU同步飙升

这种情况通常是慢查询把连接占住了,每条SQL执行时间越长，占用的连接就越久，新请求只能排队，队列一长直接打满连接数，这时候盲目杀进程没用，应该先定位慢SQL。

• 执行show processlist;看Time列的数值
• 找到执行时间超过10秒的SQL,直接kill掉对应的id
• 再通过慢查询日志定位具体SQL文

连接数过高时,第一步是止血，第二步才是治根。

慢查询优化方法：从日志到索引的完整流程

慢查询是数据库健康的核心风向标,一个数据库如果慢查询不断，CPU和连接数迟早被拖垮，慢查询优化，不能只靠调参数，要有一套可重复跑的流程。

第一步：打开慢查询日志

MySQL默认关闭慢查询日志,需要手动开启，如果不想重启实例，可以动态设置：

SET GLOBAL slow_query_log = ON;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
SET GLOBAL long_query_time = 2;

long_query_time建议从2秒起步，线上若有余量再调到1秒，注意这个参数只记录大于等于该值的语句，不含锁等待时间。

第二步：用工具定位高频慢SQL

慢查询日志文件会越来越大,人工翻阅不现实，推荐用mysqldumpslow或pt-query-digest做聚合分析，重点看三类SQL：执行次数多、总耗时高、单次耗时异常。

第三步：执行计划确认索引走向

拿到慢SQL后,用EXPLAIN分析执行计划，常见问题有：

• type出现ALL，即全表扫描
• rows估算行数远大于真实返回行数
• key为NULL，没有可用索引
• 排序字段没有索引,触发filesort

第四步：改写SQL或调整索引

索引不是越多越好,但该建的必须建，主要原则：

• WHERE条件中的字段优先建索引
• ORDER BY和GROUP BY字段考虑联合索引
• 避免对索引列做函数运算
• 用覆盖索引消除回表

一个典型场景：某订单查询按user_id和create_time过滤，原SQL走了全表扫描，加上(user_id, create_time)联合索引后，查询时间从800毫秒降到20毫秒，这就是慢查询优化的直接收益。

综合健康度评估：日常巡检和工具选型

有了单点指标还不够,数据库健康是一个动态过程，建议每周做一次巡检，把连接数峰值、CPU平均使用率、慢查询次数放在同一时间轴上对比，如果CPU峰值与慢查询峰值完全重合，说明慢查询就是CPU元凶。

巡检清单：

• 连接数使用率是否超过上限的80%
• CPU使用率是否连续30分钟高于70%
• 慢查询数量是否较上周翻倍



• 是否有长时间未提交的事务
• 临时表创建频率是否异常

对需要托管服务的场景,数据库健康检查多少钱在市场上差异较大，自建数据库用开源工具Prometheus+Grafana搭建监控，成本主要是人力投入；云数据库自带监控，按实例规格付费；如果找外部运维公司做健康检查，通常按次收费，与数据库实例数量和数据量挂钩，一线城市专业DBA服务报价会高于二三线城市，但核心差别在于是否包含SQL优化建议和容量评估。

常见问题解答

数据库监控指标有哪些容易被忽略？

连接数、CPU和慢查询之外，磁盘IO延迟和缓冲池命中率也值得关注，多数情况下，慢查询会导致磁盘读放大，而连接数过高则可能拖垮磁盘队列，建议在监控面板中把IO等待和数据库连接数放在同一张图里观察。

mysql CPU飙高一定是慢查询导致的吗？

不一定,连接数风暴、批量导入、大事务回滚、以及不合理的排序都会导致CPU飙升，如果CPU高但慢查询日志很少，优先检查show processlist中是否有大量Creating sort index或Copying to tmp table状态，这种场景需要优化排序逻辑，而不是单纯调慢查询阈值。

数据库连接数过高会直接导致服务不可用吗？

会,连接数打满后，数据库会拒绝新连接，应用层表现为获取连接超时，即使CPU还有余量，连接耗尽也会让整个服务瘫痪，建议在应用层配置连接池上限为数据库max_connections的70%，留出缓冲给管理操作和突发请求。

把连接数、CPU使用率和慢查询当作一个整体来看，数据库的健康状况就藏在这三个数字的联动关系中。下一次监控告警出现时，先看慢查询，再查连接数，最后对齐CPU时间线，基本就能锁定问题根源。 这套方法不需要昂贵工具，一条show processlist加上合理的日志分析，足以应对绝大多数日常故障。