从2秒到200毫秒：一次SQL慢查询优化全记录

上周在压测新上线的电商促销系统时，监控大屏突然告警——商品列表接口响应时间飙升到2000ms！作为核心接口，这样的延迟会让用户页面变成"PPT翻页"。今天就来复盘这次优化实战，把踩坑经验分享给大家。

一、定位瓶颈：慢查询日志揪出元凶

通过SkyWalking链路追踪，发现75%耗时集中在MySQL查询。打开慢查询日志后惊现：

# Query_time: 1.8s  Lock_time: 0.1s
SELECT * FROM products 
WHERE category_id IN (SELECT id FROM categories WHERE status=1)
ORDER BY sales_count DESC 
LIMIT 1000;

这个嵌套查询在百万级数据下引发了两个致命问题：

• 全表扫描：IN子查询导致categories表无索引遍历
• 临时文件排序：filesort消耗800ms

二、三重优化方案落地

1. 索引手术刀

给categories表增加覆盖索引：

ALTER TABLE categories ADD INDEX idx_status_id (status,id);

2. JOIN改写取代嵌套查询

SELECT p.* FROM products p
JOIN categories c ON p.category_id = c.id
WHERE c.status = 1
ORDER BY p.sales_count DESC
LIMIT 1000;

3. 引入Redis缓存层

对排序结果进行缓存，代码示例（SpringBoot）：

@Cacheable(value = "hotProducts", key = "#categoryId")
public List<Product> getHotProducts(Long categoryId) {
  // 优化后的SQL查询
}

三、优化效果对比

四、2023性能优化新趋势

除了传统手段，这些新技术值得关注：

• 向量化查询：Apache Doris支持SIMD指令加速聚合计算
• JIT编译优化：GraalVM将热点代码编译成机器码
• 智能索引推荐：阿里云DAS自动生成索引优化建议

写在最后

这次调优带来三点深刻启示：永远敬畏生产环境的数据量、EXPLAIN是SQL优化的必备工具、监控系统要提前部署。性能优化没有银弹，但掌握"定位瓶颈-各个击破-验证效果"的方法论，你也能让龟速接口飞起来！