数据库运维优化遇性能问题咋办(8个步骤轻松排查)

那天刚开电脑就收到监控报警

大清早咖啡都没喝上，企业微信突然哐哐弹警报，生产库CPU飙到95%！后台用户投诉卡成PPT。我抓起工牌就往机房跑，手都是抖的——这要是崩了今晚别想睡觉。

摸出祖传的八个排查土法子

路上脑子里把当年师父教的"三板斧"过了一遍。到工位先把监控图甩到第二屏：

• 打开系统监控工具看实时流量
• SSH连服务器输top命令
• mysqladmin status怼了三遍

第一步：看谁在吃服务器

top命令回车瞬间，好家伙！mysqld进程把16核CPU啃得就剩半个核喘气。内存倒是还富余，立马排除内存问题。

第二步：查数据库连接池

mysql里敲show processlist，屏幕刷出两百多条查询！有七八个ｓｅｌｅｃｔ憋了五分钟没动静。赶紧记下这些卡住的SQL的ID，顺手把来源IP也抄本子上。

第三步：揪出慢查询凶手

开启慢查询日志才十分钟，文件已经涨了50MB。用grep筛耗时超过3秒的语句，好么！有个统计报表的查询扫了六百万行数据，全表扫描的红字刺得我眼疼。

第四步：检查锁争夺战

输show engine innodb status拉到锁等待那节，果然有三张表被锁成麻花。最狠的ｕｐｄａｔｅ语句把用户订单表锁了整整两百秒，后面排队线程都堵到姥姥家了。

第五步：验证硬件没拖后腿

怕冤枉服务器，又查了硬盘IO：iostat -x 1显示写速度只有30MB/s，机械盘嘎吱响得像拖拉机。不过根据负载特征，这回明显是SQL的问题。

第六步：索引救火行动

把慢查询里的timestamp字段和user_id字段建联合索引。敲完alter table add index手心全是汗，生怕生产库当场罢工。结果三分钟就完事了，比预想快。

第七步：分批放行拥堵查询

找出堵得最狠的连接ID，用kill query分批干掉二十几个长查询。监控图上的CPU曲线像过山车一样咣当掉到40%，后台立马有人喊"通了通了！"

补个定时炸弹排查

顺手查了慢日志历史记录，发现这个报表查询天天跑。之前数据量小勉强能忍，最近用户暴增就炸了。赶紧给业务方打电话："兄弟你这报表得重写！"

关机前瞟了眼监控，CPU稳在25%上下波动。把咖啡渣倒进垃圾桶才发觉，自己从进门到现在连外套都没脱。所以说，数据库这玩意儿就跟老房子似的，别看平时安静，暴雨天准给你找点活儿干。