一次数据库慢查询的优化过程

前天下午Grafana告警说有个API接口的响应时间从平均200毫秒飙升到了三秒以上。排查过程记录一下，以后遇到类似问题能快速定位。

先看了应用监控面板，确认是/api/orders/list变慢了。接着用htop看服务器负载，MySQL进程的CPU从平时的5%飙升到了40%以上。基本确定是数据库的问题。

查MySQL的slow query log：mysqldumpslow -s t -t 10 /var/log/mysql/slow.log，找到一条SQL扫描了八十多万行，平均执行时间2.8秒。是orders和order_items的JOIN查询，WHERE条件里有个对日期字段的筛选。EXPLAIN一看，type是ALL——全表扫描，日期字段created_at上没有索引。

加索引：ALTER TABLE orders ADD INDEX idx_created_at (created_at)。加完之后再跑EXPLAIN，type变成range，扫描行数从80万降到1247。执行时间从2.8秒降到0.03秒。

教训：建表的时候就要考虑查询场景，高频字段一定要加索引。slow query log是排查数据库性能最好的入口，EXPLAIN是后端工程师必须会看的东西。