SQL 数据分析入门：如何把业务问题翻译成 SQL 查询

原文链接：https://www.hisqlboy.com/blog/sql-data-analysis-for-beginners

适合人群：SQL 初学者、数据分析入门者、需要把业务问题落到查询上的开发者

很多人学 SQL 时，前半段都还算顺利。

会写 SELECT，会写 WHERE，对 GROUP BY 也有一点概念。但一旦问题从"查出哪些数据"变成"分析哪个品类卖得最好""哪些客户最活跃"，就容易突然卡住。

这通常不是语法不够，而是分析思路没建立起来。

因为数据分析和基础查询的区别，不只是 SQL 更长了，而是你需要先把业务问题翻译成：

要统计什么
按什么角度看
需要哪些表
应该怎么聚合

这篇文章就讲清楚这件事。

1. 为什么"会查数据"不等于"会做分析"

先看两组问题：

查询型问题：orders 表里有哪些订单？
分析型问题：哪个商品分类卖得最好？
查询型问题：客户 1 有哪些订单？
分析型问题：哪些客户最活跃？

差别在于，分析类问题一定会引入两个核心概念：

指标（Metric）：你到底要衡量什么，比如订单数、销量、销售额
维度（Dimension）：你打算按什么角度看，比如品类、客户、日期

一旦你把指标和维度想清楚，很多 SQL 分析题其实就没那么难了。

2. 写 SQL 之前，先把业务问题拆开

假设有人问你：

本周卖得最好的商品分类是什么？

很多初学者会立刻开始写 SQL，但更稳的方式是先把问题拆掉：

"卖得最好"到底指什么？

是销量最高、销售额最高，还是订单数最多？
问题既然是按"商品分类"看，那结果就应该按分类分组。
数量可能在订单明细表里，分类可能在商品表里，所以大概率需要 JOIN。

如果这里我们把"卖得最好"定义为"总销量最高"，那这个业务问题就能转成一个非常清晰的 SQL 目标：

连接订单明细表和商品表
按分类分组
汇总销量
按结果从高到低排序

这一步其实比写 SQL 本身更重要。

3. 一个典型分析问题：哪个分类卖得最好

来看这条 SQL：

sql 复制代码

SELECT
  p.category,
  SUM(oi.quantity) AS total_units
FROM b3_items AS oi
JOIN b3_products AS p
  ON oi.product_id = p.product_id
GROUP BY p.category
ORDER BY total_units DESC;

这条查询不是随手写出来的，它和业务问题是一一对应的：

维度：p.category
指标：SUM(oi.quantity)
数据来源：订单明细表 b3_items 和商品表 b3_products
关联关系：product_id
排序方式：销量从高到低

很多初学者做分析时最大的问题，是想一步跳到答案，结果中间逻辑没想清楚。

你可以先强制自己检查 3 个问题：

表选对了吗？
维度选对了吗？
指标定义对了吗？

这三件事没错，SQL 通常就不会偏太远。

4. 为什么同一个问题，换个指标，答案就会变

还是"哪个分类卖得最好"这个问题。

如果你用的是：

sql 复制代码

SUM(quantity)

那你衡量的是"卖出的件数"。

但如果你改成：

sql 复制代码

COUNT(*)

那你衡量的更接近"订单明细记录数"。

这两个结果看起来都像在回答"哪个分类最好"，但实际上不是一回事。

这也是 SQL 数据分析里非常重要的一点：

业务问题看起来一样，指标定义不同，结论就可能完全不同。

所以在分析场景里，真正难的往往不是 SUM 怎么写，而是你知不知道自己到底在算什么。

5. 再看一个问题：哪些客户最活跃

比如我们想看客户下单活跃度，可以写：

sql 复制代码

SELECT
  c.customer_name,
  COUNT(o.order_id) AS total_orders
FROM b3_customers AS c
JOIN b3_orders AS o
  ON c.customer_id = o.customer_id
GROUP BY c.customer_name
ORDER BY total_orders DESC;

这条 SQL 的分析逻辑也一样：

指标：每个客户的订单数
维度：客户
数据来源：客户表和订单表

你会发现，很多分析题本质上都在重复这个模式：

定义指标
定义维度
找到数据表
做关联
聚合
排序或过滤

如果你把这个思路练熟，很多入门级分析题都会顺手很多。

6. SQL 分析不只有 GROUP BY，还有窗口函数

除了分组汇总，数据分析里还有一类很常见的问题：

指标是怎么随时间累积变化的？

这时候就经常会用到窗口函数。

例如：

sql 复制代码

SELECT
  order_date,
  daily_sales,
  SUM(daily_sales) OVER (ORDER BY order_date) AS running_sales
FROM b3_daily_sales
ORDER BY order_date;

这个查询的含义是：

每一天仍然保留一行
但同时额外计算"截至当天为止的累计销售额"

这和 GROUP BY 很不一样。

GROUP BY 会把多行压缩成更粗粒度的结果；

窗口函数通常保留当前行，同时给你一个新的分析视角。

对初学者来说，先记住这个区别就够了：

GROUP BY：改变结果粒度
窗口函数：通常保留结果粒度，但增加上下文信息

7. SQL 数据分析的常见思考路径

如果你遇到一个业务问题，不知道 SQL 从哪里下手，可以按下面这个顺序想：

第一步：先把问题改写成一句可计算的话

比如：

哪个分类卖得最好
哪些客户最活跃
每天销售额是怎么累计增长的

这些都比"看看数据有没有价值"更容易落地。

第二步：明确指标

问自己：

我是要看订单数？
销量？
销售额？
平均值？
累计值？

第三步：明确维度

问自己：

我要按客户看？
按分类看？
按日期看？
按城市看？

第四步：找对表和关联关系

很多分析写不出来，不是不会聚合，而是没先想清楚：

这个字段在哪张表
需要不要关联别的表
用什么键去关联

第五步：再写 SQL

这时候你再动手，思路会清楚很多。

8. 初学者最常犯的 3 个分析错误

错误 1：还没定义指标就开始写 SQL

例如别人问"哪个分类最好"，你如果没先定义"最好"是什么意思，就很容易写出一个 technically 正确、业务上却不对的查询。

因为"最好"可能是：

销量最高
销售额最高
订单数最多
利润最高

这是完全不同的分析问题。

错误 2：忘了结果的粒度

如果你的 SQL 是：

sql 复制代码

GROUP BY category

那结果里的每一行代表的是分类，而不是单个商品。

如果这一点没想清楚，就很容易拿分类级结果去解释商品级问题，结论自然会偏。

错误 3：觉得数据分析一定很复杂

其实不是。

很多有价值的业务分析，起点就是很简单的几类问题：

谁最多
哪个最好
哪天变化最大
指标是否在上升

这些问题大多数都能从 GROUP BY、ORDER BY、窗口函数这些基础能力开始做出来。

9. 一套适合初学者的 SQL 分析模板

以后你碰到新的分析题，可以直接套这个思路：

业务问题是什么？
指标是什么？
维度是什么？
需要哪些表？
用什么字段关联？
结果应该按什么顺序展示？

例如：

哪个城市的付费客户最多？

就可以拆成：

指标：付费客户数
维度：城市
表：客户表、订单表
条件：只看已支付订单

拆到这一步，SQL 基本已经快出来了。

10. 总结

SQL 真正的价值，不是在于你写出了一条多复杂的语句，而是在于你能不能把一个业务问题翻译成可验证的数据答案。

对初学者来说，最值得先练的不是炫技语法，而是这三个动作：

明确指标
明确维度
用 SQL 把两者正确连接起来

只要你能稳定回答下面这些问题：

哪个分类卖得最好
哪些客户最活跃
指标如何随时间变化

那你已经不只是"会查数据"，而是在真正开始做 SQL 数据分析了。

SQL 数据分析入门：如何把业务问题翻译成 SQL 查询

1. 为什么"会查数据"不等于"会做分析"

2. 写 SQL 之前，先把业务问题拆开

3. 一个典型分析问题：哪个分类卖得最好

4. 为什么同一个问题，换个指标，答案就会变

5. 再看一个问题：哪些客户最活跃

6. SQL 分析不只有 GROUP BY，还有窗口函数

7. SQL 数据分析的常见思考路径

第一步：先把问题改写成一句可计算的话

第二步：明确指标

第三步：明确维度

第四步：找对表和关联关系

第五步：再写 SQL

8. 初学者最常犯的 3 个分析错误

错误 1：还没定义指标就开始写 SQL

错误 2：忘了结果的粒度

错误 3：觉得数据分析一定很复杂

9. 一套适合初学者的 SQL 分析模板

10. 总结

延伸阅读