企业官网建设流程全解析

这个问题我几乎每次和数据同行交流都会被问到，而且问它的往往是两种人：一种是刚入门的数据分析师，想确认自己的技能树该往哪长；另一种是团队里的业务骨干，被各种临时取数需求压得喘不过气，想知道自己到底缺在哪一块。

先说一个我自己的观察：数据分析师的SQL能力和数据开发工程师完全是两条路线。开发要的是稳、快、省资源，一套查询要跑在生产任务里扛住千万级数据量；分析师更多时候要的是“把业务问题翻译成查询”的能力，在这种语境下，SQL的“程度”和“写过多复杂的语句”关系不大，和“能不能用最直接的方式回答业务问题”关系才大。

下面我把这个“程度”拆成四档，配合我实际干活的经验，完整讲清楚每一档到底要会什么、到什么水平才算过关，以及怎么检验自己是否真的达标。

1. 先给结论：数据分析师的SQL不需要满级，但需要四个档位

我习惯把数据岗位的SQL能力分成四个档位，这个分法不是按语法难度排的，而是按日常工作中的实用频率和决策权重排的。

第一档叫“取数能力”，对应的是刚入职场的初级分析师。这一档的核心不是写多复杂的SQL，而是“业务需求来了，能不能快速、准确地把它变成一条能跑的查询”。

第二档叫“数据加工能力”，这是中级分析师的分水岭。到了这个阶段，你不只是把数据取出来，还要在SQL层面完成指标计算、逻辑判断、时间口径处理、表与表之间的关联加工。换句话说，你要开始用SQL“做分析”，而不只是“查数据”。

第三档叫“性能意识”，这档往往被很多分析师忽视，但恰恰是它决定了你能不能在真实生产环境里活下来。一张几亿行的订单表，一个没加过滤条件的关联查询，能把调度任务拖死，也能让你在业务面前反复说“还在跑”。

第四档叫“业务串联能力”，这是高级分析师和业务专家才需要具备的。到了这一层，你要清楚不同业务场景下该用哪种查询思路，指标口径怎么用SQL固化下来，甚至你写的SQL会被下游数仓任务、报表系统反复引用。

为什么要分四档而不是更细？因为在真实招聘和团队协作里，我观察到的分界线基本就这三条：能不能独立取数，能不能独立算指标，能不能在数据量和复杂度上不翻车。每一档之间都有非常明显的差距，也对应着不同的薪资和岗位职责。

还有一个反直觉的结论：绝大多数数据分析师的日常工作里，90%的查询用的都是第一档和第二档的语法。窗口函数、CASE WHEN、JOIN、GROUP BY，这四样东西玩明白了，你已经能覆盖绝大部分分析场景。第三档和第四档更多是“意识”和“经验”，而不是“更多语法”。

所以，如果有人问我“SQL要学到什么程度”，我的答案通常是一句话：学到你能把业务问题干净利落地转化成查询，并且能在数据量变大时不慌的程度。至于那些冷门语法、底层执行原理，用到再查完全来得及。

2. 第一档“取数能力”：把业务需求翻译成查询的功夫

这一档是所有数据分析师的必修课，也是最容易被低估的一档。很多人觉得SQL入门简单，SELECT、WHERE、JOIN一学就会，但真的到了工作现场会发现，能把需求接住并转换成正确查询的人，比想象中少。

2.1 必须闭着眼写出来的六类查询

我把第一档需要具备的查询能力浓缩成六类，每一类都对应一种高频业务需求：

单表条件查询。WHERE加各种条件组合，AND、OR、IN、NOT IN、BETWEEN、LIKE，这些看起来简单，但组合起来很容易出错。尤其是NOT IN遇到NULL值时的诡异行为，踩过一次就长记性了。

聚合统计。GROUP BY配合COUNT、SUM、AVG、MAX、MIN，再加上DISTINCT去重。这一组能力的核心是理解聚合的粒度：GROUP BY后面的字段决定了结果集每一行代表什么维度，这个搞错了，后面的所有分析都白搭。

多表关联。INNER JOIN、LEFT JOIN、RIGHT JOIN，以及关联键的选择。业务里的维表、事实表、明细表之间的关系，必须能在脑海里画出来。关联最怕的是“一对多”导致的数据膨胀，明明想统计订单数，一个订单关联出三条明细，COUNT就直接翻倍了。

子查询。把一张表的结果作为条件或临时表再用一次。比如筛选出“购买次数超过平均水平的用户”，就得先用一个子查询算出平均值，再在外面套一层查询。子查询嵌套超过三层之后性能会明显下降，这是第一档靠自己写和高手帮忙写的第一个分界点。

CASE WHEN条件逻辑。在SELECT里做逻辑分支，把一堆杂乱的原始值映射成分析需要的分类值。比如把用户年龄字段切成“18-25”、“26-35”这种年龄段，或者在订单表里标记“是否大额订单”。CASE WHEN玩不转，很多分析逻辑只能放到Excel里补，效率直接打折。

时间与字符串处理。日期格式化、日期差计算、取周/月/季度、字符串截取和拼接。不同数据库的语法有差异，但思路一致。分析里90%的“时间口径”问题，靠的就是这几招。

2.2 学会“翻译”业务需求是这一档的隐藏考点

SQL语法本身不难，难的是把一段话变成一条查询。我拿一个真实的例子说明。

业务方说：“我想看上周每个城市的下单用户数，只要下单成功并且支付金额大于0的。”

这句话翻译成SQL，至少有三个坑：第一，“上周”怎么定义，自然周还是周一到周日，要不要排除今天这种不完整日期；第二，“下单用户数”是按用户ID去重还是按订单数统计，业务方经常把这两个概念混着说；第三，“支付金额大于0”是过滤订单还是过滤用户，如果一个用户有多个订单，其中一个金额为0另一个有金额，到底算不算这个用户。

我在带新人时最常做的事情，就是把业务需求拆成三个问题：看什么主体、按什么维度、用什么口径。主体是用户、订单还是商品；维度是时间、地域、品类还是渠道；口径是去重、累加、取最大还是取最新。这三个问题问清楚了，SQL的骨架就出来了，剩下的只是往里面填字段和条件。

2.3 这一档最容易翻车的三个细节

第一，JOIN产生的数据膨胀。这一点我必须多说几句。很多初级分析师写完一条JOIN，看结果数据量不对，第一反应是“数据有问题”，其实问题出在关联关系上。比如订单表和订单明细表关联，一个订单对应多条明细，如果你拿订单表做COUNT(DISTINCT订单ID)还好，一旦对订单金额做SUM，金额就会乘以明细条数。解决办法是先把明细表在子查询里聚合好，再和主表关联，确保关联前后粒度一致。

第二，COUNT的微妙差异。COUNT()统计行数，COUNT(列名)统计非NULL的行数。在LEFT JOIN场景下，右表没有匹配值时列名是NULL，COUNT(右表列)和COUNT()的结果完全不同。这个差异非常基础，但很多人栽在上面。

第三，时间条件的边界。查“3月1日到3月31日”的数据，用BETWEEN还是用>=和<，结果差一天。更稳妥的写法是开始日期用>=，结束日期用<下一个月第一天，避免时间戳带时分秒时漏掉最后一天的数据。

第一档的验收标准很简单：给你一个日常业务问题，你能在10分钟内写出一条正确的查询，并且能讲清楚每个条件的含义。到了这个水平，你已经具备了初级数据分析师的核心能力。

3. 第二档“数据加工能力”：窗口函数是绕不开的分水岭

第一档解决的是“把数据查出来”，第二档解决的是“把数据算出来”。这一档的核心武器，就是窗口函数。很多人把窗口函数当成进阶语法，实际工作中你会发现，留存率、复购率、环比同比、累计值、排名，这些分析指标几乎全部依赖窗口函数实现。

3.1 窗口函数和GROUP BY的本质区别

窗口函数最难理解的一点是：它不改变结果集的行数。

GROUP BY会把多行压成一行，而窗口函数是在每一行旁边额外计算出一个值。比如一张用户订单表，你既想看每一笔订单的金额，又想同时知道每个用户的总消费金额。用GROUP BY做不到“同时”，但窗口函数可以：

SELECT user_id, order_id, order_amount, SUM(order_amount) OVER (PARTITION BY user_id) AS user_total_amount FROM orders;

这条查询的结果里，每一笔订单旁边都多了一列“该用户的总消费金额”，但行数没有变化。这个特性在计算占比、累计值、同期群分析时特别有用。

理解窗口函数的关键是抓住三个部分：函数本身（SUM、AVG、ROW_NUMBER、LAG这类）、PARTITION BY（相当于窗口内部的GROUP BY，决定按什么分组）、ORDER BY（决定窗口内的排序方式，尤其是累计计算时很重要）。

3.2 日常工作里最常用的四个窗口场景

第一个场景是排名。ROW_NUMBER、RANK、DENSE_RANK三个函数长得像，结果差别很大。ROW_NUMBER不管并列，给每个行唯一编号；RANK有并列会跳号；DENSE_RANK有并列但不跳号。做“Top 10用户”分析时，到底用哪个取决于业务是否需要并列名次。

第二个场景是累计值。SUM(金额) OVER (ORDER BY 日期)能算出从第一天到当前天的累计销售额。这是分析“年初至今累计”类指标的标准写法。这里ORDER BY的位置决定了“累计”的窗口范围，如果是PARTITION BY加ORDER BY，就是每个分组内部的累计。

第三个场景是环比和同比。LAG函数能取到上一行的值，比如按月份排序后，LAG(销售额, 1)就是上个月的销售额。用当前值减上个月值再除以上个月值，就能快速算出环比增速。同比同理，LAG(销售额, 12)在月度数据里就是去年同期。没有LAG函数的时候，这些计算得靠自关联，既啰嗦又容易错。

第四个场景是移动平均。AVG(销售额) OVER (ORDER BY 日期 ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)，能算出过去7天的移动平均销售额。这在做趋势平滑、排除节假日波动影响时很常用。

3.3 从“会语法”到“会算指标”：留存的完整写法

光会语法不够，第二档真正的考验是拿窗口函数组合出业务指标。我拿用户留存率举个例子，这是数据分析面试里出现频率最高的题目之一。

需求：计算最近30天每天新增用户的次日留存率。

思路分三步：第一步，先找出每个用户的首单日期，也就是新增日期；第二步，找到该用户所有下单日期中，距离首单日期恰好为1天的记录；第三步，按首单日期分组，用留存用户数除以新增用户数。

一个可行的写法：

WITH user_first_order AS ( SELECT user_id, MIN(order_date) AS first_order_date FROM orders GROUP BY user_id ), user_retention AS ( SELECT uf.user_id, uf.first_order_date, o.order_date FROM user_first_order uf LEFT JOIN orders o ON uf.user_id = o.user_id AND o.order_date = DATE_ADD(uf.first_order_date, INTERVAL 1 DAY) ) SELECT first_order_date, COUNT(DISTINCT user_id) AS new_users, COUNT(DISTINCT CASE WHEN order_date IS NOT NULL THEN user_id END) AS retained_users, COUNT(DISTINCT CASE WHEN order_date IS NOT NULL THEN user_id END) / COUNT(DISTINCT user_id) AS retention_rate FROM user_retention GROUP BY first_order_date ORDER BY first_order_date;

这个写法里，子查询、LEFT JOIN、日期函数、CASE WHEN、COUNT DISTINCT全都用上了。能独立写出这样的查询，说明第二档的加工能力已经过关。

我见过很多候选人能背出窗口函数的语法，但一遇到“算留存”就卡壳。卡壳的原因不是语法没记住，而是不知道“先用子查询定位首单日期，再用JOIN关联次日订单”这个分析链路。所以第二档的学习重点其实是分析思路：拿到一个指标，先拆出需要的中间表，再用SQL把这些表拼接起来。

4. 第三档“性能意识”：从能跑到跑得快，靠的是执行计划

很多人觉得性能优化是DBA的事，数据分析师只要把数据跑出来就行。这个想法在数据量小的时候没毛病，可一旦进了真实生产环境，一张表几千万行是常态，一条烂查询能跑半小时，直接把你的工作效率拖入泥潭。

4.1 我经历的一个慢查询排查过程

有一回我写一条分析“各品类最近30天销售情况”的SQL，逻辑很简单：订单明细表和商品维表关联，再做分组聚合。结果跑了快20分钟还没结束，查询任务直接被打回。

当时的排查链路是这样的：先用EXPLAIN看执行计划，发现订单明细表走了全表扫描，扫描行数接近9000万。再一看，关联条件里我给商品维表的关联字段加了函数处理，导致索引失效。把函数去掉之后，查询时间从20分钟降到了40秒。

这个案例给我的教训是：性能问题大多数时候不是数据库配置问题，而是SQL写法问题。常见的原因无非这几种：

索引没生效。关联字段或过滤字段上套了函数、做了隐式类型转换，索引就废了。比如WHERE order_date = '2024-01-01'，如果order_date是日期类型，字符串会被自动转换，性能影响不大；但如果字段是字符串类型而你传了别的类型，就可能触发隐式转换，放弃索引。

SELECT了不必要的列。这里不是说不能SELECT *，而是分析任务动辄返回几十个字段，实际上只用三五个。字段越多，IO开销越大，在大表上差别非常明显。输出前只保留需要的字段，是成本最低的优化手段。

关联顺序和过滤时机不对。应该先在小结果集上过滤，再去JOIN大表，而不是先JOIN再过滤。很多人写SQL时习惯把过滤条件放在WHERE后面，觉得结果一样就行。但对于优化器来说，过滤条件越早应用，中间结果集越小，执行效率越高。

4.2 分析师需要懂的三个性能核心概念

第一个是索引的选择性。索引不是建得越多越好，而是看字段的区分度。区分度高的字段（用户ID、订单号）适合建索引，区分度低的字段（性别、状态）建了索引也可能被优化器忽略，因为全表扫描反而更快。分析师不需要会建索引，但要知道“为什么这条查询快、那条查询慢”，底层原因基本都和索引有关。

第二个是分区与分桶。数仓里的表通常会按日期分区，查询时加上日期分区过滤，数据扫描量可以从几亿行降到几百万行。分析师的习惯是：凡是要跑全量数据的任务，先问自己“真的需要全量吗”，能不能用最近30天、最近90天替代。

第三个是JOIN的驱动顺序。小表驱动大表是基本常识。虽然现在很多引擎会自动优化，但理解这个原理能帮你在写SQL的时候主动把大表的过滤条件写清楚，而不是把所有希望寄托在优化器身上。

4.3 第三档的“二八定律”

性能优化是个无底洞，分析师不需要学成专家。我的经验是抓两头：一头是让查询“能出来”，另一头是让查询“别太慢”。具体来说，记住三个自查习惯就够了：

写完查询先看预估扫描行数。EXPLAIN会告诉你这个查询会扫多少行。如果扫描行数和最终结果行数差距几个数量级，说明过滤条件可能没写好。

尽量避免在关联和过滤字段上做运算。不管是函数、拼接还是类型转换，都可能导致索引失效。宁可多写一层子查询，也不要在关键字段上做手脚。

能用分区过滤一定要加分区过滤。尤其是跨月份的查询，按天分区能帮你把数据量缩小几个数量级。别觉得加个日期范围是理所当然的事，我看到过太多人写查询不带日期条件，一跑就是全表。

第三档的验收标准是：给你一张几千万行的表和一条业务查询需求，你有能力判断这条查询会不会慢，并且能通过调整写法把查询时间降到可接受的范围。

5. 第四档“业务串联能力”：SQL深度取决于你服务的业务阶段

前三个档位讨论的是“怎么把SQL写好”，第四档要讨论的是“好到什么程度才算够用”，而这取决于你服务的业务阶段和你的岗位角色。

5.1 不同岗位对SQL程度的差异化要求

做面向业务部门的数据分析、做数据产品和指标体系的数据分析，以及偏数据挖掘的算法型分析，三者对SQL的要求完全不同。

贴近业务运营的分析师，日常最重的活儿是取数和看板维护。这类岗位SQL要求最实用：能写复杂的多表关联和窗口函数，能快速产出日/周/月维度报表，能响应业务方层出不穷的口径调整。重点是快和准，追求的是高并发处理临时需求的效率。

偏数据产品方向的分析师，核心职责是把指标口径固化下来。这类岗位要求的是建模思维：你要能用SQL准确表达一个指标的完整定义，包括排除哪些异常数据、按什么维度汇总、使用什么样的去重规则。你写出来的SQL会被下游任务长期引用，所以稳定性和可读性比单次执行的效率更重要。

偏算法和实验方向的分析师，SQL和Python双修，SQL主要用于样本抽取、特征表构建和实验数据分析。这一类的SQL不用很花哨，但一定要懂和数仓的协作边界：哪些表可以直接取，哪些逻辑应该沉淀在数仓层，哪些特征适合在SQL里算、哪些应该拉回Python再处理。

5.2 指标体系背后的SQL思维

第四档的深度其实主要体现在一件事上：你能不能把复杂的业务口径翻译成一套稳定的SQL模板。

以“新客首购30日复购率”为例。不同人写出来的SQL可能完全不一样，但结果应该一致。核心在于你怎么定义“新客”、怎么定义“首购”、怎么定义“复购”、怎么计算“30日”。

• 新客：第一次下单的用户，通常用用户的首次支付日期来判断
• 首购：用户的第一笔有效订单，排除退款单和测试单
• 复购：用户支付的第二笔订单
• 30日：从首购日期起算的30个自然日

把这些口径串起来，你需要用到子查询来定位首单日期，用到窗口函数来给订单排序，用到条件过滤来剔除异常单。第四档的人写出来的SQL，不仅结果正确，而且能保证别人接手时看一眼就明白口径是怎么定义的。

我见过最糟糕的情况是一个指标在报表里和临时分析里口径不一致，两边数字对不上，业务方直接失去信心。这本质上不是SQL的问题，是对口径理解不统一的问题。但SQL作为指标落地的最终载体，分析师能把这些口径用清晰的查询表达出来，本身就是一种很强的业务串联能力。

5.3 四档能力在面试中的体现

面试数据分析岗时，我通常用三个问题来快速定位候选人的SQL水平：

第一题是“查一张销售表各月的销售额”，这是第一档的入门题，考察GROUP BY和日期函数的基本功。

第二题是“算每个用户购买次数排名前3的商品”，这题需要窗口函数配合子查询，考察第二档的加工能力。能写出来的候选人大约占到六成。

第三题是“分析为什么最近7天销售额下降了20%”，这题没有标准答案，考察的是第四档的业务串联能力。有人会写SQL排查哪些品类下降，有人会按渠道拆解，有人会去查流量变化和转化率。SQL在这里只是工具，真正被考察的是分析思路和拆解框架。

面试这件事给我最大的感触是：SQL语法可以速成，但“用SQL思考业务”的能力需要时间沉淀。如果你正在学习阶段，与其追求把所有函数背下来，不如多在真实业务场景里练手，把“销售额下降”“留存变差”这类问题当成SQL练习的素材。

6. 一个综合场景，检验你的SQL真的达标没

光说不练没有用。这一节我设计一个综合业务场景，覆盖从第一档到第四档的能力要求。你可以试着不参考任何资料写一写，感受一下自己的水平卡在哪一档。

6.1 业务需求描述

假设有一个某零售平台的订单表 orders，字段包括：order_id（订单ID）、user_id（用户ID）、product_id（商品ID）、category（商品品类）、order_date（下单日期）、order_amount（订单金额）、pay_status（支付状态，成功/失败/已退款）。

需要你分析：2024年第四季度，每个品类的“新客首购后30天内二次购买率”。

二次购买的定义是：该用户首购日期之后30天内（含第30天），产生了第二笔支付成功的订单。

6.2 推荐的实现思路

第一步，找出每个用户的首购日期。用MIN(order_date)按user_id分组，别忘了只在2024年第四季度范围内找首购订单，并且只取支付状态为成功的订单。

第二步，给订单打上“是否首购”和“是否二次购买”的标记。这里可以用窗口函数ROW_NUMBER按用户和下单日期排序，也可以用两步JOIN的方式。推荐用窗口函数，逻辑更紧凑。

第三步，按照首购订单的品类分组，计算每个品类下面的首购用户数和其中完成二次购买的用户数，相除得到二次购买率。

一个简化的SQL框架是这样的：

WITH paid_orders AS ( SELECT order_id, user_id, product_id, category, order_date, order_amount FROM orders WHERE pay_status = '成功' AND order_date BETWEEN '2024-10-01' AND '2024-12-31' ), user_first AS ( SELECT user_id, MIN(order_date) AS first_date FROM paid_orders GROUP BY user_id ), flagged AS ( SELECT p.category, p.user_id, p.order_date, uf.first_date FROM paid_orders p JOIN user_first uf ON p.user_id = uf.user_id ) SELECT category, COUNT(DISTINCT CASE WHEN order_date = first_date THEN user_id END) AS first_purchase_users, COUNT(DISTINCT CASE WHEN order_date > first_date AND order_date <= DATE_ADD(first_date, INTERVAL 30 DAY) THEN user_id END) AS second_purchase_users, COUNT(DISTINCT CASE WHEN order_date > first_date AND order_date <= DATE_ADD(first_date, INTERVAL 30 DAY) THEN user_id END) / NULLIF(COUNT(DISTINCT CASE WHEN order_date = first_date THEN user_id END), 0) AS repeat_purchase_rate FROM flagged GROUP BY category;

注意几个细节：

• COUNT(DISTINCT CASE WHEN ... THEN user_id END) 这种方式避免了先筛后聚合导致的数据行数变化，也便于一眼看出口径。
• NULLIF把分母为0的情况转成NULL，避免出现除零错误。
• first_date = order_date 匹配的才是首购订单；order_date > first_date 避免把同一天的多次订单误判成二次购买。

写完这条SQL之后，你自己可以拿着结果自查几个问题：每个品类的首购用户数之和，是不是等于全平台第四季度的首购用户总数？二次购买用户数是不是一定小于等于首购用户数？不同品类的repeat_purchase_rate加起来为什么没有意义，而应该各自独立解读？

能把这些问题想清楚，说明你的SQL水平已经不只是“会写”，而是真正理解了数据分析要的是什么。

6.3 写好之后，再往深想一步

综合场景里最容易出错的地方有三个：第一个是首购日期的归属范围，如果一个用户10月没有首购而是10月之前就首购了，第四季度首购品类的统计里不应包含他；第二个是退款单要不要剔除，这里我在前面已经剔除了，但真实业务里退款和成功可能并存，需要结合业务定义；第三个是30天的计算口径，是自然日还是工作日，含不含首购当天，都要明确定义。

实际做分析时，我还会延伸一步：不仅要算每个品类的二次购买率，还要看这个指标在不同渠道、不同价格区间上的差异。因为SQL能帮你把精确口径的指标算出来，但指标背后“为什么有这个差异”的分析逻辑，才是真正体现数据分析价值的地方。

7. 学习路径和时间线：多久能到这个程度

后台也经常有人私信问我，零基础学SQL做数据分析，到底要学多久才能找工作。我给一个参考路径，但先说清楚：这个时间线是每天能保证2-3小时学习时间的前提下估的，掌握程度按前面说的第二档到第三档之间的水平来算。

7.1 零基础入门：约三个月

第一个月打基础。主攻第一档的内容：SELECT、WHERE、ORDER BY、GROUP BY、聚合函数、基础的JOIN和子查询。这个阶段不需要追求写得多复杂，关键是每天坚持写几条查询，把语法变成肌肉记忆。

第二个月进阶。进入第二档：CASE WHEN逻辑、日期函数、字符串函数、窗口函数（排名、累计、LAG/LEAD）。这个月要配合真实业务问题来练，比如用公开数据算留存率、复购率、Top品类排名。学窗口函数最大的坎是理解“不改变行数的计算”这个概念，琢磨明白之后，后面就是套用的问题。

第三个月进入实战和优化。把前两个月的知识串起来，做综合性的分析练习，同时开始看执行计划，理解索引和分区的基本原理。如果有机会，找一些数据量比较大的练习环境，感受一下数据量对查询性能的影响。

7.2 有Excel统计基础：时间减半

如果你的Excel和统计分析基础比较好，已经习惯用数据透视表、VLOOKUP做数据处理，那么SQL的很多概念可以平移过来。数据透视表的分组汇总就是GROUP BY，VLOOKUP的查找匹配就是JOIN，Excel里的IF嵌套就是CASE WHEN。这种情况下，SQL只是换了个工具做同一件事，学习成本主要在语法和工具切换上，一个半月到两个月就能到第二档水平。

7.3 每天练什么，比练多久更重要

我给一个很具体的建议：找一个在线判题网站，把SQL题目的简单到中等难度刷掉100道左右，再集中做10道左右的综合业务类题目。刷题的意义不在于背答案，而在于建立“看到问题立刻想到对应语法”的条件反射。

还有一件事值得坚持：每周手写一版指标计算SQL，不是用鼠标点工具，而是在编辑器里从零开始写。留存率写一遍、复购率写一遍、环比同比写一遍，写错不要紧，关键是写完后对着结果想一下“这个数字和业务常识对不对得上”。数据敏感度也是在这样一次一次的核对中练出来的。

按照这个节奏走下来，三个月左右你会明显感觉到：接到一个数据需求，不再急着问别人怎么取数，脑子里已经能快速浮现出查询的骨架了。到时候你就达到了“数据分析师该有的SQL程度”的第一阶段——而这种“自己搞得定”的感觉，才是真正让你在后续学习里越走越顺的底气。