前言
数据分析师工作中，SQL是最核心的技能之一。但很多人的SQL写得很慢，查询跑了10分钟还不出结果，严重影响工作效率。
本文结合实际案例，分享SQL优化的核心思路，帮助你把查询速度从10分钟优化到1分钟以内。
一、为什么SQL会慢
SQL查询慢的本质原因只有一个：扫描了太多数据。理解这一点，所有的优化手段都能推导出来。
常见的慢查询原因：
-
SELECT * 全表扫描
-
WHERE条件没有索引
-
JOIN没有正确的连接条件
-
GROUP BY/DISTINCT 数据量太大
-
子查询嵌套层数过多
二、案例分析：订单报表优化
2.1 原始查询（耗时8分钟）
SELECT
o.order_id,
o.user_id,
o.order_time,
o.amount,
u.username,
u.city,
p.product_name,
p.category
FROM orders o
LEFT JOIN users u ON o.user_id = u.user_id
LEFT JOIN order_items oi ON o.order_id = oi.order_id
LEFT JOIN products p ON oi.product_id = p.product_id
WHERE o.order_time >= '2025-01-01'
AND o.order_time = '2025-01-01'
AND order_time
优化阶段耗时说明
原始查询8分钟全表扫描
添加索引3分钟索引生效
减少扫描45秒先筛再JOIN
最终优化12秒综合优化
**提升倍数：40倍**
## 三、常用优化技巧总结
### 3.1 索引优化
-- 组合索引遵循最左前缀原则 -- 创建组合索引 CREATE INDEX idx_col1_col2 ON table_name(col1, col2);
-- 查询能命中索引的情况 WHERE col1 = 'xxx' -- ✅ 命中 WHERE col1 = 'xxx' AND col2 = 'yyy' -- ✅ 命中 WHERE col2 = 'yyy' -- ❌ 不命中
-- 避免在索引列上使用函数 WHERE YEAR(create_time) = 2025 -- ❌ 不命中索引 WHERE create_time >= '2025-01-01' -- ✅ 命中索引
### 3.2 LIMIT分页优化
-- 优化前（深分页慢） SELECT * FROM orders ORDER BY order_id LIMIT 1000000, 20;
-- 优化后（基于ID分页） SELECT * FROM orders WHERE order_id > 1000000 ORDER BY order_id LIMIT 20;
### 3.3 COUNT优化
-- 优化前（COUNT * 全表扫描） SELECT COUNT(*) FROM orders WHERE status = 1;
-- 优化后（使用索引计数） SELECT COUNT(1) FROM orders WHERE status = 1;
-- 或者维护统计表（实时性要求不高时）
## 四、如何判断SQL性能
使用 EXPLAIN 分析执行计划：
EXPLAIN SELECT * FROM orders WHERE order_time >= '2025-01-01';
-- 关键字段说明： -- type: 连接类型（const > eq_ref > ref > range > ALL） -- key: 实际使用的索引 -- rows: 预计扫描行数 -- Extra: 额外信息（Using index, Using filesort等）
## 五、总结
SQL优化的核心原则：
- **减少数据扫描量**：WHERE条件尽量精确
- **合理使用索引**：为高频查询字段建索引
- **避免全表扫描**：不用SELECT *，少用函数
- **优化JOIN顺序**：小表驱动大表
- **分析执行计划**：用EXPLAIN定位问题
记住：SQL优化是一个持续的过程，没有银弹，只有不断分析和迭代。
---
**作者简介**：船长，数据分析师，关注数据分析、职场成长、投资理财。
