MySQL性能优化实战：慢查询到毫秒响应全链路突破

　　凌晨三点十七分，告警声像指甲刮黑板，三十七条慢查询告警叠在钉钉弹窗里，第十八秒我划开手机屏幕，指纹解锁失败两次——左手还攥着半凉的美式，杯沿那圈咖啡渍糊住了工牌上的“张伟”俩字，斜斜盖住“高级技术培训师”烫金字。DBA老周的微信弹出来：“又来了”，后头跟个没发出去的语音，七秒，他大概咽回去了。我盯着那个“又”字看了四秒，不是生气，是后怕——这词儿用得太熟了，熟得像呼吸。

　　ssh到从库那台机器的时候，手指在键盘上停了半秒。先输ip，再回车，等它吐出密码提示，再输密码（错了一次，Caps Lock没关），再回车。中间空调嗡的一声，冷风猛地压下来，机房那股混合着金属味和旧网线皮焦糊气的味道就顶到了嗓子眼。我原以为又是索引缺失，结果explain出来的type居然是ALL，但key_len却显示用了联合索引的前两列——这个我敢打包票，不是你建的索引有问题，是你WHERE里那个函数包裹的字段，把索引给废了。可你说谁会想到用UNIX_TIMESTAMP(now()) - UNIX_TIMESTAMP(create_time) > 86400？后端小李去年八月份写的，他说“老板说要查‘昨天’的数据”，我就没拦，拦了他也听不懂什么叫索引失效的边界条件。

　　对面工位那个穿拖鞋的运维，上周换了双蓝白拼接的，鞋带系得歪斜，脚后跟踩着鞋帮来回磨，啪嗒、啪嗒。我盯着他脚看三秒，忽然想起调休申请的事——上个月15号交的，被驳回，理由是“非项目关键期”。呵。关键期？三百七十二条告警堆在飞书群里的时候，谁算关键期？

　　改SQL不难，把那个减法挪到应用层，换成日期范围查。难点是动完以后，测试环境跑得飞起，生产一上就卡在JOIN的临时表溢出上。我翻日志看到tmp_table_size被撑到128M才溢出磁盘，可老板说“加内存快”，DBA老周直接把my.cnf里max_heap_table_size调成256M重启——没用。因为那张临时表根本不是内存能扛住的规模，是逻辑结构烂：三张大表LEFT JOIN，其中两张只用id关联，第三张却用name做LIKE模糊匹配。我说换inner，他说业务要“兼容NULL值”。行吧。后来我干脆在FROM里套了个子查询预过滤，把name LIKE那一块先抽成物化结果——结果MySQL 5.7不支持CTE物化，只能强行WITH RECURSIVE骗过语法校验（其实根本不递归），靠hint强制走临时表，再加force index。这操作我跟谁都不敢说，说出来像在讲玄学。

　　最反常识的是：性能真提上去了，但从“3.2秒”压到“87毫秒”，真正起效的不是索引重建，不是参数调优，不是读写分离，而是把那个凌晨两点手动触发的binlog purge脚本，改成每小时执行一次，并加了sleep 300。为什么？因为当时主从延迟抖动的峰值，全卡在PURGE时IO毛刺上——而purge又恰好撞上了备份任务启动的时刻。没人查这个。连监控图都平滑得像PS过的。就那天凌晨，空调嗡了一声之后，我顺手点了下Zabbix里那个“binlog size trend”子图表，放大到分钟粒度，看见purge动作后整整六分半钟磁盘IOPS跌了73%，CPU user反而涨了——这才意识到，不是SQL慢，是它等在队列里，前面排着个“假装在删除”的假人。

　　老板说“这次优化很成功”，拍我肩膀时候力道太重，震得我刚放下的保温杯盖子弹开一条缝。我没接话。他转身去会议室讲“技术杠杆价值”了。我打开自己去年八月份写的课件初稿，翻到“优胜劣汰”那页，批注写着：“不是算法更优，是活下来的SQL，刚好没撞上那三次IO毛刺+连接池泄露+凌晨DNS超时的叠加态。”这话我现在删掉了。太虚。真实的情况是：某条SQL活下来，就因为它在某个凌晨四点十七分，比隔壁那条早0.4秒拿到了连接句柄。就这么简单。

文章配图，仅供参考

　　昨天值班表贴出来了，我排在周四。小李问我能不能换，他老婆产检。我没答应也没拒绝，只说“看看周四早上会不会又响”。他手机响了一声，没接，放在桌面上，锁屏亮着，壁纸是张婴儿B超图，边缘有点泛黄。窗外天已经灰透了，但还没亮。我合上笔记本，咖啡渍干在工牌上，裂成蛛网状。

　　下周我打算在新课里砍掉两页“执行计划解读”，换上一张纯黑背景图，只打一行字：“EXPLAIN不是诊断书，是遗嘱草稿。”——先扔结论，后面细节补不补，随缘。反正学员也懒得细看。我自己现在，也不信了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!