SQL思维进阶训练(第二回)

如果你写过一阵子 SQL，大概会有这种体验：单表查询、简单 JOIN、GROUP BY 都不太费劲，可一旦问题变成「上个月来过、这个月又来的用户有多少」，手上就开始卡壳。这不是语法不熟，而是把业务问题翻译成查询结构的思路还没建立起来。这门课针对的正是这道坎。

先确认自己是不是该学这一回

这门课基于 MySQL，围绕用户登录日志这类常见表结构展开。判断要不要花时间，可以看几个具体信号：

• 写多条件统计时，习惯性地堆子查询，写完自己都读不下去；
• 遇到「日活」「月活」能写出一个数，但说不清口径差异在哪；
• 留存率的 SQL 抄过一次，换张表就不知道怎么改；
• 分不清 WHERE 和 HAVING 该在哪一步过滤，靠试错凑结果；
• 日期函数用得不顺手，跨月、跨天边界总要反复验证。

上面中了两三条，说明缺的不是函数手册，而是把需求拆成集合运算的过程。如果连基本的 SELECT、JOIN、GROUP BY 都还没写熟，建议先补基础再来，否则容易变成照着敲一遍、合上就忘。

这门课真正想解决的问题

课程把「统计类 SQL」拆成了一条可以复用的思路链：先明确指标口径，再确定数据粒度，然后决定在哪一层做聚合，最后才是写函数。日活和月活的区别，本质是去重维度不同；留存的分母和分子，分别对应两个时间窗口的用户集合，中间靠 JOIN 或子查询把「同一批人」对上。

跟着练下来，你应该能自己回答几个问题：为什么日活不能直接把登录次数加起来；为什么留存的日期要用偏移量对齐而不是硬编码；同一份日志表，怎么在不改表结构的前提下算出周活。这些问题的答案比记住某段 SQL 更有用，因为它们决定了你换一个业务场景后还能不能写出来。

练习环节要当作重点

统计类 SQL 有个特点：看别人写觉得简单，自己动手就出错。所以配套练习不是可选项。建议的做法是，每看完一个指标的计算方式，先关掉示例，凭记忆写一遍，再对照差异。差异往往不在语法上，而在粒度选错、过滤时机放错、或者 JOIN 条件漏了限定。

练习时值得留意几处容易翻车的地方：时间范围的开闭区间，比如「近 7 天」到底含不含今天；跨月统计时按自然月还是按滚动 30 天；去重用户时用 DISTINCT 还是 GROUP BY，两者在后续关联时的表现并不一样。把这些边界情况都跑一遍，比多刷十道同类型的题更有价值。

学完之后可以自查的标准

与其问「学到了什么」，不如用几个具体任务检验：给你一张带用户 ID 和时间戳的日志表，能否在十分钟内写出次日留存、7 日留存，并说明每一步为什么这么写；能否解释你写的查询在数据量翻十倍后，哪一段可能变慢、可以先从哪里改；能否把同一套思路迁移到订单表或访问记录表上，而不是只会套用登录日志。

如果这几个问题还答不利索，说明练习量不够，回头再跑一遍案例比继续往下学更划算。SQL 的进阶从来不靠多记函数，而靠把一类问题想清楚一次，然后反复验证。