数据库变慢时，按“资源等待→内部争用→SQL执行→基础设施”四层看，优先确认CPU/磁盘I/O、锁等待和活跃连接数，别一上来就翻慢查询日志。
生产环境数据库突然变慢监控哪些指标最有效
数据库突然变慢时，它不会直接告诉你哪里疼，你需要像急诊分诊一样，先确认生命体征，生产环境里最优先看的四个维度是：CPU、内存、磁盘I/O、网络，这四个任何一项先触顶,后面的SQL优化都白搭。
- CPU使用率：用
top -H -p $(pgrep mysqld)看线程级别。us高，多半是SQL计算量过大；sy高，可能是锁自旋或上下文切换；wa高，说明CPU在等磁盘,这时候去优化SQL索引收益很小。 - 内存与交换分区：重点看
vmstat里的si和so，一旦发生swap，数据库性能会出现断崖式下降，内存不够还会导致缓冲池被挤压,磁盘读自然变多。 - 磁盘I/O等待：
iostat -x 1 5看await、util、r/s、w/s，磁盘队列深度一旦拉高,再快的SQL也得排队等货架搬运。 - 网络延迟与丢包：应用服务器到数据库之间的RTT、重传率要盯住，云上跨可用区或本地机房到云专线质量差,会让简单查询也显得慢。
数据库就像一个仓库管理员，CPU是算账速度，磁盘I/O是搬货速度，连接数是同事数量，一个环节堵了，整体吞吐就掉下来，先看这几个指标，能把问题范围缩小到“资源层”还是“数据库层”。
MySQL慢查询和连接数哪个先看？先分清等待类型
很多同学第一反应是开慢查询日志，但如果连接数已经被打满，慢查询只是结果，不是原因。MySQL慢查询和连接数哪个先看,判断顺序其实很直接：
- 先看连接数和活跃线程，执行
SHOW GLOBAL STATUS LIKE 'Threads_connected';和SHOW GLOBAL STATUS LIKE 'Threads_running';，如果连接数接近max_connections，大量请求在排队,先处理连接堆积。 - 再看会话状态，执行
SHOW PROCESSLIST;，按State
分组，如果一堆会话卡在
Waiting for table metadata lock或Waiting for table level lock,说明锁等待是主要矛盾。 - 最后才看慢查询日志，连接数正常但单个SQL执行时间很长，再按
Rows_examined排序找扫描行数大的SQL。
不要拿慢查询数量当唯一依据，一个执行计划错误的SQL，可能扫描几百万行数据，产生大量磁盘读，把整个库拖慢，先分清是“等锁”“等I/O”还是“等CPU”,比直接看慢查询更靠谱。
数据库变慢怎么排查监控指标：从等待事件到执行计划
资源层看完，如果CPU和磁盘都没打满，问题大概率藏在数据库内部。数据库变慢怎么排查监控指标，重点要转向等待事件、缓冲池命中率、事务日志和锁等待。
- 缓冲池命中率：执行
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';和SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';，命中率明显下降时，说明内存不够用，磁盘读变多，行业共识认为，数据库变慢的根因相当一部分集中在SQL执行计划与索引设计,资源瓶颈往往是表象。 - 事务日志等待：
SHOW ENGINE INNODB STATUSG里看 redo log 相关部分。log sequence和log flushed差距持续拉大，说明日志刷盘跟不上,写入会被拖慢。 - 锁等待：MySQL 5.7 查
information_schema.innodb_lock_waits，8.0 推荐sys.innodb_lock_waits，锁等待会让连接堆积,表现出连接数升高但CPU不忙。 - 执行计划突变：
EXPLAIN看type、key、rows、Extra，出现Using filesort和Using temporary时，排序和临时表会拖慢SQL，执行计划可能因统计信息变化而改变,不能只看一次。
实操命令示例：
SHOW ENGINE INNODB STATUSG
SELECT FROM sys.innodb_lock_waits;
EXPLAIN ANALYZE SELECT ...;等待事件是数据库的“疼痛位置”，MySQL 用 performance_schema，PostgreSQL 用 pg_stat_activity，从等待事件反推瓶颈,比盲目重启服务有效得多。
云数据库监控费用对比：开源工具与云监控怎么选
很多中小企业在选监控方案时，第一反应是看价格。云数据库监控费用对比下来,其实分成三类：
| 方案 | 费用模式 | 指标深度 | 维护成本 |
|---|---|---|---|
| 云厂商基础监控 | 免费 | 资源层+基础数据库指标 | 低 |
| 云厂商增强监控 | 按量付费，价格随存储天数和实例规格变化 | SQL明细、等待事件、执行计划 | 低 |
| 开源Prometheus+Exporter | 软件免费，需服务器和运维人力 | 高度自定义，几乎所有指标 | 中高 |
云厂商基础监控多数免费，能覆盖CPU、内存、连接数、磁盘IOPS这些日常告警，但像SQL洞察、性能洞察这类增强功能，通常按存储时长或实例数计费，不同厂商价格差异较大，开源方案用 Prometheus + Grafana + mysqld_exporter，软件本身免费,但需要一台监控服务器和持续运维。
不要只盯着监控软件费用，数据库变慢一次的业务损失，往往超过一年的监控成本，中小企业更适合从云厂商基础监控起步,等遇到复杂性能问题时再短期开启增强监控。
中小企业数据库性能监控方案：北京企业本地机房与云上RDS怎么选
地域因素会影响监控方案和网络延迟。北京企业数据库性能监控方案大致分两条路：本地机房和云上RDS。
- 北京本地机房：需要自建监控，用 Zabbix 或 Prometheus 采集服务器硬件状态，包括温度、风扇、RAID、磁盘健康，同时用
mysqld_exporter采集数据库指标，专线延迟、机房电力、硬件故障都要纳管,不能只盯数据库本身。 - 云上RDS：北京地域的RDS自带监控面板，但必须设置阈值报警，重点配置 CPU使用率、内存使用率、连接数、IOPS、磁盘空间、网络出入流量，如果跨可用区部署,主备同步延迟也要监控。
- 实操建议：云监控里创建报警规则，CPU使用率超过70%持续5分钟发告警，连接数超过80%发告警，慢查询数量突增发告警，本地机房用 node_exporter 采硬件，mysqld_exporter 采数据库，Alertmanager 统一发通知。
北京本地机房到用户侧的专线质量会直接影响数据库响应时间，云上RDS则要注意可用区选择，应用和数据库尽量放在同一VPC同一可用区,否则跨地域网络抖动会让简单查询也变慢。
实操：数据库变慢时监控指标排查清单
把上面的维度串成一条排查路径,出问题时按顺序执行：
- 先看OS层：
top、iostat、vmstat，确认CPU、磁盘、网络哪个先饱和。 - 看连接数与活跃线程：
SHOW STATUS LIKE 'Threads_%',判断连接是否打满。 - 看会话状态：
SHOW PROCESSLIST或查information_schema.processlist，按State分组。 - 看等待事件：
performance_schema.events_waits_current，确认是锁、I/O还是网络。 - 看慢查询：按
Rows_examined排序,找扫描行数突变的SQL。 - 看执行计划：
EXPLAIN ANALYZE，检查type和rows。 - 对比基线：从监控系统拉出最近7天曲线,看哪些指标在变慢前1小时开始异常。
核心逻辑是先定界，再深入，不要用猜，不要一上来就重启数据库，重启只能暂时掩盖问题，监控指标没抓到,下次还会在同一个地方跌倒。
Q&A
数据库变慢怎么排查监控指标？
先查OS层的CPU、磁盘I/O和网络，确认资源是否饱和，再看连接数和活跃线程，然后查锁等待和慢查询，最后用 EXPLAIN 看执行计划，按这个顺序，多数情况下能在十分钟内把瓶颈方向定位到资源层、锁等待层或SQL层。
MySQL慢查询和连接数哪个先看？
连接数先看，连接数接近上限时，大量请求在排队，慢查询只是结果，连接数正常后，再翻慢查询日志，按执行时间和扫描行数排序,找真正拖垮性能的SQL。
云数据库监控费用一般多少？
基础监控免费，增强监控如SQL洞察和性能洞察按存储天数计费，每月从几十元到几百元不等，取决于厂商、实例规格和留存时长,最终成本与是否需要长期审计留存直接相关。