MySQL慢查询排障：从发现到根治的完整路径

上周三凌晨两点，某电商客户的客服群炸了——用户反馈下单后页面转圈近十秒才响应。运维同学第一反应是查服务器负载，CPU正常、内存正常、带宽也正常。翻到MySQL慢查询日志才发现，一条看似普通的订单查询语句，执行时间从平时的50毫秒飙升到了8秒。

慢查询是怎么冒出来的

很多人以为慢查询是突然出现的，其实不是。大多数情况下，它是数据量增长到某个临界点后暴露的。这位客户的订单表现在有800万条记录，查询条件用的是一个没有索引的status字段。数据量小的时候全表扫描也快，数据量一大，问题就藏不住了。

排查慢查询，先打开慢查询日志。在my.cnf里配置slow_query_log=1，long_query_time设为1秒，重启生效。或者在线动态开启：SET GLOBAL slow_query_log=ON。别设太低，0.1秒会把日志撑爆，反而影响排查效率。

拿到慢SQL之后怎么分析

用EXPLAIN看执行计划，重点关注三个字段：type列如果是ALL说明全表扫描，必须优化；key列如果是NULL说明没用上索引；rows列如果远大于实际返回行数，说明索引设计有问题。

那个客户的情况很简单——给status字段加个联合索引就搞定了。但加索引不是拍脑袋的事，得考虑写入性能的折损。高频更新的字段加索引要慎重，可以通过监控写入QPS的变化来评估影响。

三个建议帮你少踩坑

第一，定期巡检慢查询日志，建议每周跑一次pt-query-digest做汇总分析，别等用户投诉才发现问题。第二，建立SQL审核流程，上线前的SQL必须过EXPLAIN，type为ALL的拒绝上线。第三，设置合理的long_query_time，核心业务库建议设为0.5秒，这样能更早发现性能退化趋势。

数据库性能问题从来不是突然爆发的，而是日积月累的结果。把慢查询监控做扎实，比事后救火省心得多。