MySQL性能优化实战：17年经验直击慢查询到毫秒响应

　　去年八月份那阵子，业务方突然冲进我工位，说订单查询接口从三百毫秒跳到三秒，手机一直在震，全是用户投诉。我原以为又是索引没打全的老毛病，结果翻慢查询日志，好家伙，一条SELECT FROM orders WHERE status=1 ORDER BY create_time DESC的语句，扫描了八百多万行——可业务方明明说这表就二十万数据啊？

　　运维在旁边翻监控，说“你看这连接数，从早到晚蹭蹭涨，下午三点直接冲到两千五”。我盯着SHOW PROCESSLIST，发现二十多个会话全卡在同一个SQL上，每个都卡了快二十秒。业务方还在旁边嚷嚷：“这表绝对没超过二十万，我上周刚查过！”我让他把建表语句发过来，一看——好家伙，status字段是VARCHAR(20)，可查询条件里写的是status=1，MySQL这傻逼引擎居然没报类型转换警告，默默把全表扫了遍！

文章配图，仅供参考

　　改完类型转换的问题，查询时间从三秒掉到八十毫秒，可业务方不依不饶：“用户说还是慢，能不能再快点？”我翻执行计划，发现ORDER BY的create_time字段没索引——业务方说“这字段肯定有索引啊，我让前端传了排序参数的”。我让他把前端代码发过来，结果发现他们传的是“createTime”，而数据库字段名是“create_time”，中间多了个下划线！MySQL这傻逼引擎又默默做了隐式转换，把索引给废了。我骂了句“这帮人写代码全靠猜吗”，业务方在旁边小声嘀咕：“我们以为数据库会自动匹配的…”

　　改完字段名匹配的问题，查询时间掉到三十毫秒，可业务方又说“用户说偶尔会超时”。我翻错误日志，发现一阵一阵的“Lock wait timeout exceeded”——原来他们为了“保证数据一致性”，把所有订单操作都加了事务，可事务里还混着调用第三方支付接口的操作。我原以为支付接口最多卡两秒，结果那天第三方系统抽风，卡了五秒，直接把数据库连接池撑爆了。运维在旁边补刀：“我早上还看到有会话卡了十分钟，最后被MySQL主动杀了。”

　　窗外天亮了，我盯着屏幕上的慢查询日志，突然想起十七年前刚入行时，带我的老师傅说过的话：“MySQL优化没别的，就是优胜劣汰——把该打的索引打上，把该改的代码改了，把该杀的会话杀了，剩下的慢查询，要么是业务逻辑太复杂，要么是硬件不够硬。”我回头看业务方，他们还在纠结“为什么不能把查询时间压到十毫秒以内”，我叹了口气：“你们先保证代码里别写status=1这种傻逼查询，别用错字段名，别把长事务和外部调用混在一起，剩下的，我慢慢调。”

　　其实到现在我也没完全搞明白，那天的慢查询到底是哪个环节先爆的——是类型转换、字段名不匹配、长事务，还是第三方接口卡顿？可能都有吧。但有一点我笃定：MySQL性能优化这事儿，永远是“你退一步，它进一步；你进一步，它退一步”。就像去年八月份那次，我熬了一整夜，改了类型、加了索引、杀了会话，最后查询时间从三秒掉到三十毫秒，业务方才勉强满意——可我知道，过不了多久，他们又会因为新需求改代码，然后新的慢查询又会冒出来。

　　下一步我打算补个监控脚本，专门抓“类型转换警告”和“隐式字段名匹配”的日志——反正业务方不会主动查，只能我替他们盯着。至于能不能防住下一次慢查询？谁知道呢，反正这十七年，我早习惯了。

（编辑：站长网）

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