性能突降首要排查慢查询和阻塞会话：用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 STATUS\G
重点看三块：
-
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 积分余额。
