mysql性能突然下降怎么排查_mysql运行异常分析

性能突降首要排查慢查询和阻塞会话：用SHOW PROCESSLIST或information_schema.PROCESSLIST查TIME>60且非Sleep的活跃会话，重点关注Waiting for table metadata lock等状态；同时确认slow_query_log是否开启并分析高频慢sql；再检查INNODB STATUS中的锁等待、缓冲池及系统层I/O、内存、CPU和配置漂移。

查看当前正在执行的慢查询和阻塞会话

性能突降最常见原因是某个长事务或未优化 SQL 占用大量资源，导致后续请求排队。先连上 mysql，用 SHOW PROCESSLIST 快速看有没有 State 长时间停留在 Sending data、Sorting result 或 Locked 的线程。

更进一步，查 information_schema.PROCESSLIST 并过滤掉 Sleep 状态：

SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO  FROM information_schema.PROCESSLIST  WHERE COMMAND != 'Sleep' AND TIME > 60  ORDER BY TIME DESC LIMIT 10;

重点关注 TIME 超过 60 秒且 STATE 非空闲的会话；若发现 State 是 Waiting for table metadata lock，大概率是 DDL（如 ALTER TABLE）被阻塞，需找源头连接并 kill 掉。

检查慢查询日志是否开启及最近高频慢 SQL

很多线上库默认关闭 slow_query_log，突降时再开已来不及。先确认当前状态：

SHOW varIABLES LIKE 'slow_query_log';

如果为 OFF，立刻开启（注意：这不会影响已有连接，但会增加磁盘 I/O）：

• 临时开启：SET GLOBAL slow_query_log = ON;
• 同时设阈值（比如 1 秒以上算慢）：SET GLOBAL long_query_time = 1.0;
• 日志路径通常在：/var/lib/mysql/slow.log 或由 slow_query_log_file 变量指定

别只盯着平均耗时——用 mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log 查调用次数最多、总耗时最高的前 10 条 SQL，它们往往才是压垮数据库的“惯犯”。

确认 InnoDB 缓冲池与锁等待是否异常

InnoDB 的 innodb_buffer_pool_size 配置不合理，或突发大量写入引发页分裂/锁争用，都会让响应陡增。运行以下命令观察关键指标：

SHOW ENGINE INNODB STATUSG

重点看三块：

• SEMAPHORES 下是否有持续增长的 os_waits —— 表示内核级锁竞争严重
• TRANSACTIONS 中 lock Struct(s) 数量突增，且出现 waiting for this lock to be granted —— 表明行锁/间隙锁阻塞
• BUFFER POOL AND MEMORY 中 Free buffers 长期接近 0，而 database pages 波动剧烈 —— 缓冲池可能太小或被大扫描刷爆

若发现大量 LOCK WAIT，结合 information_schema.INNODB_TRX 和 INNODB_LOCK_WAITS 定位阻塞链，例如：

SELECT r.trx_id waiting_trx_id, r.trx_mysql_thread_id waiting_thread,        b.trx_id blocking_trx_id, b.trx_mysql_thread_id blocking_thread,        r.trx_query waiting_query FROM information_schema.INNODB_TRX b JOIN information_schema.INNODB_LOCK_WAITS w ON b.trx_id = w.blocking_trx_id JOIN information_schema.INNODB_TRX r ON r.trx_id = w.requesting_trx_id;

排查系统层资源瓶颈和 MySQL 配置漂移

MySQL 自身没问题，不等于没故障。常见“假性数据库问题”包括：

• 磁盘 I/O 饱和：iostat -x 1 看 %util 是否长期 >90%，await 是否飙升（>50ms）
• 内存不足触发 swap：free -h 和 cat /proc/swaps 确认是否在用 swap，一旦启用，MySQL 性能断崖下跌
• CPU 被其他进程吃满：top -c 按 P 排序，看是不是 mysqld 线程 CPU% 很低，但系统整体 load 很高
• 配置被意外修改：对比 mysqld --verbose --help | grep "default" 和当前 SHOW VARIABLES，特别关注 innodb_log_file_size、max_connections、query_cache_type（MySQL 8.0+ 已移除）等易被误调项

一个容易被忽略的点：某些云厂商的“突发性能实例”会在 CPU 积分耗尽后限频，此时 top 看 mysqld 占用率极低，但查询全卡住 —— 要查云平台监控里的 CPU 积分余额。