mysql调优工具经验分享！快速提升性能50%！

系统慢到姥姥家了

上周三早上，一开电脑就看到测试群炸锅了。铺天盖地都是“页面刷不出来”、“转圈圈转得我要睡觉了”的抱怨。我们那个破系统，平时访问量一上来就跟老牛拉破车似的，这回彻底趴窝了。领导直接在我工位旁边敲桌子：“搞快点！用户投诉电话快把客服打爆了！”我心里苦，这破MySQL数据库，数据量也就百来万条，咋就这德行？

抄起工具开干

第一反应先摸出系统监控工具看负载。好家伙，CPU直接飙到90%多，内存也快见底了。敲了个top命令，发现MySQL这货吃资源跟饿死鬼投胎一样。但光知道它饿了没用，得知道它为啥饿。我反手就祭出SHOW PROCESSLIST，一长溜执行列表刷出来，当场血压就上来了——一堆SQL语句挂着“Sending data”状态，有的甚至跑了十几分钟还没完！

赶紧锁定那几个跑得最欢的进程ID，打开percona toolkit（这玩意儿真是DBA的救命稻草），对着问题进程ID一顿操作：

pt-query-digest --processlist h=localhost --filter '$event->{arg} =~ /PID=12345/'

结果跳出来几条长得要命的SQL，定睛一看差点昏古七——有个查用户订单历史的语句，居然在百万级数据表里玩全表扫描！连个像样的索引都没有，怪不得慢得像乌龟爬。

给SQL动手术

揪出罪魁祸首就好办了。先拿EXPLAIN照妖镜照它一照：

EXPLAIN ｓｅｌｅｃｔ  FROM order_history WHERE user_id=456 ORDER BY create_time DESC;

结果明晃晃写着type=ALL，rows列显示要扫90多万行。我大腿一拍：“索引兄弟！”。立马掏出脚本给user_id和create_time这俩字段捆了个组合索引：

ALTER TABLE order_history ADD INDEX idx_user_time (user_id, create_time);

等索引建完手都在抖。重新执行EXPLAIN——type=ref，rows瞬间降到200多！当场打开终端试跑原SQL，原来20秒的查询直接干到0.3秒。边上的实习生小哥都看呆了：“这就...完事了？”

意外收获的坑

刚想嘚瑟，测试组老张突然从厕所冲出来：“注册页面崩了！”赶紧查日志，发现个新报错：“Lock wait timeout exceeded”。头皮一麻，又开SHOW ENGINE INNODB STATUS翻事务锁信息，好嘛有张用户表被某个凌晨跑数据的定时任务锁得死死的。

扭头就把那个憨批任务的SQL拆了：
原来：ｕｐｄａｔｅ user SET vip_level=3 WHERE expire_date < NOW()
改成：分批处理，每次只更新500条，更新完睡0.1秒再接着干。这下锁冲突直接消失，注册功能秒恢复。

血泪换来的教训

• 监控永远打头阵：CPU/内存不对劲立马查进程，别瞎猜
• 慢查询日志是照妖镜：percona那把日志嚼碎了喂你吃
• EXPLAIN必须焊死在SQL前：没它分析等于蒙着眼开刀

调完那天晚上压测报告出来，领导群里发了个红包——峰值处理能力真从原来每分钟400请求提到600了。虽然离50%还差点，但页面加载从平均5.7秒干到2秒内，测试组那帮人终于不追着我骂了。这波折腾值了！