慢SQL优化实战：手把手教你从5秒到0.1秒的蜕变之路

最新推荐文章于 2025-05-24 18:41:44 发布

notion2025

最新推荐文章于 2025-05-24 18:41:44 发布

阅读量935

点赞数 17

文章标签： sql 数据库其他

本文链接：https://blog.csdn.net/notion2025/article/details/147979862

版权

文章目录

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

最近在技术社区看到一个有趣的投票：程序员职业生涯中最怕遇到的十大问题中，慢查询优化竟然高居前三（仅次于线上故障和生产数据丢失）！今天咱们就来场硬核实战，把我去年处理的一个真实慢查询案例拆解给你看，绝对比教科书上的示例更接地气！

一、问题定位：慢查询的"犯罪现场"

当时接手的是一个电商平台的订单统计报表功能，用户反馈导出的Excel经常卡死。通过MySQL的慢查询日志（show variables like ‘slow_query%’），我们很快锁定了这个耗时5.2秒的"元凶"：

SELECT 
    o.order_id,
    u.username,
    p.product_name,
    SUM(oi.quantity) AS total_quantity,
    COUNT(DISTINCT oi.sku_id) AS sku_variants 
FROM orders o
JOIN users u ON o.user_id = u.user_id
JOIN order_items oi ON o.order_id = oi.order_id 
JOIN products p ON oi.product_id = p.product_id
WHERE o.create_time BETWEEN '2023-01-01' AND '2023-12-31'
GROUP BY o.order_id
HAVING sku_variants > 3
ORDER BY total_quantity DESC
LIMIT 1000;

EXPLAIN诊断报告（关键指标）：

type: ALL（全表扫描警告！）
rows: 280万（触目惊心）
Extra: Using temporary; Using filesort（双重暴击）

二、优化五步走战略

第一步：索引手术刀（关键！）

-- 原有索引
ALTER TABLE orders ADD INDEX idx_user (user_id);

-- 优化后复合索引
ALTER TABLE orders ADD INDEX idx_time_user (create_time, user_id);
ALTER TABLE order_items ADD INDEX idx_order_product (order_id, product_id);

原理：把WHERE条件字段和JOIN字段组合成复合索引，利用最左前缀原则。实测查询速度从5.2s→1.8s！

第二步：拆解复杂查询

把HAVING条件转移到子查询：

SELECT * FROM (
    SELECT 
        ... -- 原查询字段
    GROUP BY o.order_id
) AS temp 
WHERE sku_variants > 3

效果：减少GROUP BY后的数据量，执行时间1.8s→1.2s

第三步：拒绝临时表

在my.cnf增加配置：

tmp_table_size=256M
max_heap_table_size=256M

注意：服务器内存小于32G的不要盲目调大！我们案例中临时表大小约180M，调整后Using temporary消失，耗时1.2s→0.9s

第四步：文件排序优化

-- 原ORDER BY
ORDER BY total_quantity DESC

-- 优化为预计算
ALTER TABLE orders ADD COLUMN total_quantity_cache INT;
UPDATE orders SET total_quantity_cache = (...) -- 定期更新