MySQL 慢查询优化实战:从 8 秒到 80 毫秒

前阵子为一个客户排查订单报表慢查询,一个统计接口耗时 8 秒,明显不可接受。定位过程很有代表性,分享出来供参考。

第一步看执行计划:发现 WHERE 条件里的日期字段有函数包裹,导致索引失效,全表扫描。去掉函数、改为范围查询后,耗时降到 1.2 秒。

第二步看回表:查询的列分散在多个索引中,优化器选择主键回表读取,数据量大时开销惊人。通过建立覆盖索引,把查询列全部纳入索引,耗时进一步降到 180 毫秒。

第三步是业务层面的优化:报表数据无需实时,引入定时汇总表,最终接口耗时稳定在 80 毫秒以内。优化慢查询,永远是「先看执行计划,再谈索引设计,最后考虑业务架构」。