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

　　器械区那股铁味混着前台的老歌飘过来，老张把杠铃片摔得震天响——他总说“大力出奇迹”，可上个月硬拉伤了腰，现在还在做离心收缩复健。我靠在深蹲架边，看他扶着腰慢慢蹲下，突然想起去年12月那场MySQL优化，跟现在这场景有点像：都他妈是优胜劣汰，没实力的迟早被淘汰。

　　那阵子能推个大概——双十二大促前三天，订单系统突然卡成PPT。监控显示慢查询堆成山，最夸张的SQL跑了12秒，CPU直接干到98%。我原以为调几个索引就能搞定，结果改完发现执行计划根本没变——EXPLAIN里还是全表扫描，像会员硬拉时腰没绷直，怎么喊“核心收紧”都没用。

　　后来翻日志才发现，优化器选了错误的索引。老王叼着烟凑过来：“你改的索引选择性太低，跟会员用20kg做深蹲一样，看着热闹其实没效果。”他甩给我一张纸，上面画着索引覆盖率的对比图，“试试把WHERE条件里的字段全加上联合索引，像深蹲时脚掌抓地一样，把查询路径锁死。”

　　我照着改完，执行计划确实变了，但查询时间只降到8秒。镜子上那块手印是会员做卧推时蹭的，我盯着它发了会儿呆，突然想起老张上次硬拉受伤前也说过“感觉不对劲”。翻出慢查询日志，发现有个子查询在循环里跑，像会员做组间休息时刷手机，看似没消耗其实在偷偷耗电。把子查询改成JOIN，时间直接砍到3秒——这时候老张在拉伸区打哈欠，我冲他喊：“看见没？这就是技术代偿！”

　　但真正的突破在第四天。测试环境跑得好好的，生产环境一上线又卡了。我蹲在深蹲架边啃指甲，地上有个用了一半的粉笔，是教练画动作路线用的。老王突然拍我肩膀：“你改完索引没更新统计信息！”原来MySQL的优化器依赖统计信息做决策，就像会员做动作要靠本体感觉——信息不准，动作肯定变形。执行ANALYZE TABLE后，查询时间从3秒蹦到200毫秒，像会员突然解锁了标准动作，重量蹭蹭往上涨。

　　不过有个细节我现在也没完全想明白。最后优化到80毫秒时，我发现有个字段在WHERE条件里永远是NULL，但索引里却包含了它。按理说NULL值不会被索引，可删除这个字段后查询反而慢了10毫秒。老王说可能是优化器的“诡异偏好”，就像有些会员做卧推时非要把杠铃杆掰弯，你说他错吧，他还真能推起来；你说他对吧，又总觉得哪里不对劲。

　　说到这儿想起个会员——小李，去年夏天非要练CrossFit，我说他深蹲幅度不够，他非说“功能性训练不需要标准动作”。结果三个月后膝盖疼得下不了楼，现在还在做股四头肌等长收缩。这跟MySQL优化一样：你偷的懒，系统迟早会还回来。那些慢查询就像代偿动作，短期能糊弄过去，长期看必受伤。

文章配图，仅供参考

　　前台的老歌换成了《海阔天空》，老王在教新教练怎么用pt-query-digest分析日志。我摸了摸深蹲架上的杠铃杆，上面还留着小李上次训练时的汗渍。这行当就这样：你以为掌握了所有技巧，结果总有个细节教你做人——就像现在，我依然没搞懂为什么删除那个NULL字段索引会变慢，但至少知道，遇到这种“反常识”情况，先别急着下结论，多测几遍再说。

（编辑：站长网）

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