MySQL性能问题排查与优化实战

1. 问题现象与初步判断

上周五凌晨3点，我正在家里睡得正香，突然被一阵急促的手机警报声惊醒。抓过手机一看，监控系统显示生产环境的MySQL实例CPU使用率已经飙到了98%。作为一个有五年数据库运维经验的老手，我立刻意识到这不是普通的波动，而是一个需要立即处理的严重性能问题。

登录服务器后，我首先用top命令确认了情况。果然，mysqld进程独占了一个CPU核心的98%资源。这种情况通常意味着：

• 有慢查询正在全表扫描
• 索引失效导致查询效率低下
• 锁等待导致大量连接堆积
• 服务器资源不足

重要提示：处理生产环境性能问题时要先保留现场证据，不要贸然重启服务。我立即执行了pt-stalk收集诊断数据，这个习惯在后续分析中帮了大忙。

2. 系统级排查手段

2.1 实时监控关键指标

我习惯使用一套组合命令快速获取系统全景：

bash复制# CPU和进程监控
top -c -H -p $(pgrep -d, mysqld)

# IO状况
iostat -xm 2

# 网络连接
netstat -antp | grep mysqld

# 内存使用
free -h

这次发现：

• CPU的sys占比异常高（35%）
• 磁盘util保持在90%以上
• 有大量SYN_SENT状态的连接

2.2 MySQL全局状态分析

进入MySQL后，我立即抓取了关键指标：

sql复制SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW ENGINE INNODB STATUS\G
SHOW PROCESSLIST;

发现：

• Threads_running=127（严重超出正常值）
• 大量连接卡在"Sending data"状态
• InnoDB显示有10个长事务运行超过300秒

3. 深度SQL分析

3.1 捕获问题SQL

使用pt-query-digest分析慢日志：

bash复制pt-query-digest /var/log/mysql/mysql-slow.log --since '2023-07-20 02:00:00'

输出显示一个统计报表查询占据了78%的慢查询时间：

sql复制SELECT