一个真实的故事
我在百度做数据产品经理的第二年,有一次业务方急需一份用户留存数据报告,数据分析师那周全在忙另一个大项目。我等了两天没等到,最后自己打开 SQL 编辑器,花了 20 分钟写了一段查询,把数据拉出来了。
那是我第一次真正感受到:会 SQL 的 PM 和不会 SQL 的 PM,在工作效率上是两个物种。
后来我面试了不少 PM 候选人,发现一个规律:能自己写 SQL 拉数据的候选人,对业务的理解深度明显更强。因为他们不是在看别人整理好的数据报表,而是自己去数据库里探索,能发现很多报表里看不到的东西。
所以,产品经理需要学 SQL 吗?我的答案是:不是"需要",而是"必须"。
为什么 PM 必须学 SQL?
1. 摆脱对数据分析师的依赖
大厂的数据分析师资源永远是稀缺的。一个分析师可能同时支持 3-5 个 PM,你提的数据需求排到下周才能处理是常态。如果你自己会 SQL,简单的数据查询 10 分钟就能搞定,不用等人。
2. 面试硬性要求
2026 年,字节跳动、美团、快手、拼多多等公司的 PM 面试,SQL 几乎是必考项。不是让你写多复杂的查询,但至少要能现场写出基础的聚合查询和多表关联。
3. 提升数据敏感度
当你自己去数据库里查数据时,你会对数据表结构、字段含义、数据质量有更深的理解。这种理解会反过来提升你的产品设计能力——你会更清楚哪些数据能采集、哪些指标能计算、哪些分析能做。
4. 和工程师更好地沟通
懂 SQL 意味着你理解数据库的基本逻辑,和工程师讨论技术方案时不会完全听不懂。这在 B 端产品和数据产品的场景下尤其重要。
SQL 基础语法:PM 必须掌握的部分
SELECT:查询数据
-- 查询用户表中所有用户的姓名和注册时间
SELECT user_name, register_time
FROM users
WHERE register_time >= '2026-01-01'
ORDER BY register_time DESC
LIMIT 100;这是最基础的查询语句。SELECT 选择要查的字段,FROM 指定表名,WHERE 设置筛选条件,ORDER BY 排序,LIMIT 限制返回行数。
WHERE:条件筛选
-- 查询活跃用户(最近7天有登录)
SELECT user_id, user_name, last_login_time
FROM users
WHERE last_login_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
AND status = 'active';WHERE 子句支持多种条件:=、>、<、>=、<=、!=、BETWEEN、IN、LIKE、IS NULL 等。多个条件用 AND 或 OR 连接。
JOIN:多表关联
-- 查询用户的订单信息
SELECT u.user_name, o.order_id, o.order_amount, o.create_time
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
WHERE o.create_time >= '2026-01-01';JOIN 是 PM 必须掌握的重点。实际业务中,数据分散在不同的表里,你需要通过 JOIN 把它们关联起来。
LEFT JOIN:左表全部保留,右表匹配不上的显示 NULL(最常用)INNER JOIN:只保留两个表都能匹配上的记录RIGHT JOIN:右表全部保留(很少用)
PM 最常用的是 LEFT JOIN,因为你通常想保留所有用户,即使他们没有订单记录。
GROUP BY:分组聚合
-- 统计每个渠道的注册用户数和付费用户数
SELECT channel,
COUNT(*) AS total_users,
SUM(CASE WHEN is_paid = 1 THEN 1 ELSE 0 END) AS paid_users,
ROUND(SUM(CASE WHEN is_paid = 1 THEN 1 ELSE
GROUP BY 是数据分析的核心。配合 COUNT、SUM、AVG、MAX、MIN 等聚合函数,可以做各种维度的统计分析。
HAVING:对聚合结果筛选
-- 找出月活跃用户数超过1000的城市
SELECT city, COUNT(DISTINCT user_id) AS mau
FROM user_login_log
WHERE login_time >= '2026-03-01' AND login_time < '2026-04-01'
GROUP BY city
HAVING COUNT(DISTINCT user_id) > 1000
ORDER BY mau DESC;HAVING 和 WHERE 的区别:WHERE 在分组前筛选,HAVING 在分组后筛选。当你需要对聚合结果设置条件时,用 HAVING。
业务场景 SQL:PM 面试高频题
场景一:计算次日留存率
-- 计算2026年3月每天的次日留存率
SELECT a.login_date,
COUNT(DISTINCT a.user_id) AS day_users,
COUNT(DISTINCT b.user_id) AS retained_users,
ROUND(COUNT(DISTINCT b.user_id) * 100.
留存率是 PM 面试最高频的 SQL 题。核心思路是:用自关联(self join)把同一个用户在不同日期的登录记录关联起来。
场景二:漏斗分析
-- 电商购买漏斗:浏览 -> 加购 -> 下单 -> 支付
SELECT
COUNT(DISTINCT CASE WHEN event = 'view' THEN user_id END) AS view_users,
COUNT(DISTINCT CASE WHEN event = 'add_cart' THEN user_id END) AS cart_users,
COUNT(DISTINCT CASE WHEN event
漏斗分析的 SQL 相对简单,核心是用 CASE WHEN 对不同事件分别计数。面试时可能会追问:如何计算每一步的转化率?如何按渠道拆分漏斗?
场景三:用户分层(RFM 模型)
-- 基于最近消费时间和消费金额对用户分层
SELECT user_id,
DATEDIFF(CURDATE(), MAX(order_time)) AS recency_days,
COUNT(*) AS frequency,
SUM(order_amount) AS monetary,
CASE
WHEN DATEDIFF(CURDATE(), MAX(order_time)) <= 30 AND SUM(order_amount) >= 1000 THEN '高价值活跃'
RFM 模型是用户运营的经典分析框架,面试中经常出现。核心是用 CASE WHEN 根据不同维度的阈值对用户进行分类。
面试常考 SQL 题型总结
| 题型 | 核心知识点 | 难度 |
|---|---|---|
| 次日/7日留存率 | 自关联、DATE函数 | ⭐⭐⭐ |
| 漏斗转化分析 | CASE WHEN、COUNT DISTINCT | ⭐⭐ |
| 用户分层/RFM | GROUP BY、CASE WHEN | ⭐⭐⭐ |
| 连续登录N天 | 窗口函数、日期差 | ⭐⭐⭐⭐ |
| TopN问题 | ROW_NUMBER窗口函数 | ⭐⭐⭐ |
| 同比/环比计算 | LAG窗口函数 | ⭐⭐⭐ |
| 去重统计 | COUNT DISTINCT、子查询 | ⭐⭐ |
窗口函数:面试加分项
窗口函数是 SQL 进阶内容,但在面试中出现频率越来越高。PM 至少要了解两个:
ROW_NUMBER:排名
-- 每个品类销售额Top3的商品
SELECT *
FROM (
SELECT product_name, category, sales_amount,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales_amount DESC) AS rn
FROM products
) t
WHERE rn <= 3;LAG/LEAD:同比环比
-- 计算每月GMV的环比增长率
SELECT month,
gmv,
LAG(gmv) OVER (ORDER BY month) AS last_month_gmv,
ROUND((gmv - LAG(gmv) OVER (ORDER BY month)) * 100.0 / LAG(gmv) OVER (ORDER BY month),
学习资源推荐
入门阶段(1-2周)
- W3Schools SQL Tutorial:最简洁的 SQL 入门教程,有在线练习环境
- SQLZoo:交互式 SQL 练习平台,边学边练
- 牛客网 SQL 专项练习:国内最好的 SQL 刷题平台,题目贴近大厂面试
进阶阶段(2-4周)
- LeetCode SQL 题库:按难度刷,先 Easy 再 Medium
- 《SQL必知必会》:经典入门书,薄薄一本,一周能看完
- 实际业务练习:找一个公开数据集(如 Kaggle),模拟业务场景写查询
持续提升
- 在工作中主动用 SQL 拉数据,遇到不会的语法现查现学
- 关注数据分析师的技术博客,学习他们的查询思路
- 用 ChatGPT / Cursor 辅助学习,把业务需求描述给 AI,看它生成的 SQL,然后理解每一行的含义
常见误区
误区一:PM 需要精通 SQL
不需要。PM 需要的是"够用"的 SQL 能力,能独立完成 80% 的日常数据查询就够了。复杂的数据建模和性能优化是数据工程师的事。
误区二:学 SQL 要先学数据库原理
不需要。PM 学 SQL 就像学开车,你不需要懂发动机原理,会操作就行。直接从 SELECT 语句开始学,遇到问题再补知识。
误区三:Python 可以替代 SQL
不能。Python 和 SQL 的使用场景不同。SQL 是直接查询数据库的语言,Python 更适合做数据清洗和复杂分析。对 PM 来说,SQL 的优先级远高于 Python。
总结
SQL 对产品经理来说,不是一个"加分项",而是一个"基本功"。它不需要你花很长时间学习——集中两周时间,每天练习 1-2 小时,就能掌握面试和日常工作需要的 SQL 能力。
记住一句话:能自己拉数据的 PM,永远比等别人给数据的 PM 更有竞争力。