正文：
作为专注数据分析结论/项目在业务落地以实现增长的分析师，建议在开始学习新技能前，先明确应用场景。有的放矢才能不枉费努力。
翻译过来就是：先了解与SQL相关的数据分析工作有哪些？有了目标，才能知道需要准备什么知识来应对。
按我目前与SQL相关的工作内容，为你提供以下参考：
（食用说明：根据以下场景，选择需要重点学习的知识点）
SQL应用场景及必备知识：
(星标根据使用频率标记，而非重要性)
数据查询 ★★★
业务场景
也就是常说的“提数”。
实际工作场景中，如果向IT提提数需求，一般都需要沟通+排期，所以最有效率的建议就是自己会从数据库里提数
数据分析师除了自身的分析工作外，有时(甚至是经常)还需要应付产品、运营等部门同事的提数需求
必备知识
- 简单查询
即最简单的关键字组合SELECT +FROM +WHERE +(BETWEEN /IN) 是SQL查询的地基
此简单查询可以应对部分提数需求，例如运营想查看某段时间订单
- 多表查询
即INNER JOIN、LEFT JOIN 等联结关键字
想象中的取数可能是直接在某个表SELECT想要的字段？
NO! 实际上为了查询效率，数据会散落到数据库的各个角落，例如想要了解一笔订单情况，信息存在这些表中：订单流水表、订单详情表、商品详情表、门店表、会员表等。
该部分知识的关键在于「明确业务分析需求→选择合适的联结方式」
数据更新 ★★☆
业务场景
即题主所说的“增删改”
该场景之所以仅两星的原因，是实际工作中，数据库运维部门给到我们数据分析师的数据库账号多半是只读权限，也就无法去“增删改”；
此外，还有数据管控的原因
所以此场景可能更多在于自建数据库中，如在电脑上新建虚拟机搭建数据库服务器，导入数据后方便进行下一步分析
必备知识
- 数据库与表的创建、删除和更新
该部分知识点关键在于「字段类型的设置」要符合后续分析需求，如订单商品数量就要设成数值类型、订单日期设成日期类型等。
(因为见过都设成字符类型的表，所以就简单提一下)
分析数据 ★★★
业务场景
该部分可谓是数据分析师的核心工作
面对复杂的业务问题，重点在于将其拆解、转译成简单的SQL问题
「案例」例如教育行业中某领导要求你“分析某课程的效果如何”→ 翻译：
课程效果可通过学生成绩反映，即是要计算成绩最大值、最小值、学生成绩分布 → SQL语句
必备知识
- 汇总分析
即GROUP BY关键字
解决业务问题：
如计算每个课程学生的平均成绩：
SELECT avg(成绩) FROM 成绩表 GROUP BY 课程
- 复杂查询
如嵌套子查询、标量子查询、关联子查询
可应对更复杂的业务问题：
如找出每个课程最高分的学生 → 需要按课程分组后找到最高成绩记录，可以应用关联子查询：
SELECT 学生名字 FROM 成绩表 a WHERE 成绩 = (SELECT max(成绩) FROM 成绩表 b WHERE a.课程=b.课程)
- 窗口函数
聚合/排序函数 ( ) OVER (PARTITION BY ..ORDER BY..)
此函数可解决复杂业务问题，如常见的TOP N问题：
找出每个课程成绩前三的学生 → 按课程分组对学生按成绩排名，再从中找出排名前三的学生：
SELECT 学生名字 FROM ( SELECT 学生名字, dense_rank()over(partition by 课程 order by 成绩 desc) as '成绩排名' FROM 成绩表) t WHERE t.成绩排名<4
数据产品 ★☆☆
业务场景
对于部分岗位，如我在的集团用户数据中心，需要负责搭建如CDP这样的数据产品，虽然多数情况下是由开发负责数据库工作，但是对于里面核心的功能如运营指标体系、模型报表等，背后的计算逻辑、数据流，要求数据分析师了如指掌。
此外，对于刚开始建立数据分析团队的部门，还存在【数据同步】的需求，即要从ERP、CRM等系统将需要分析的原数据同步到自己的数据库里便于分析，而此需求需要通过存储过程实现。
必备知识
- 存储过程
即PROCEDURE，可以将某业务需求，或者数据产品中的报表对应的所有SQL语句放在一起，方便一键执行，如RFM模型里的语句可以写成存储过程，计算结果实时同步到前端
- 「SQL SERVER」计划
面对「数据同步」需求，有了存储过程后，还需要进行定时任务，在非业务时间执行数据同步的存储过程。
如是使用SQL SERVER版本，可以通过“计划”实现定时任务。
项目部署 ★☆☆
业务场景
数据分析结论在业务场景测试有效后，就需要通过报表、模型等方式落地形成业务常态。
而这个项目落地，可能交给开发处理，但更有效的方式是分析师可以参与到部署的过程中。
而这个过程，其中一个重要的部分就是数据库的设计：
如何设计表格以提高计算效率。
必备知识
- 数据库设计与「SQL三范式」
SQL三范式的目的在于解决数据冗余、计算效率低等问题，另一方面对数据增加、修改更友好。
这部分从业务场景出发，讨论业务问题的解决方案与SQL知识点的关系，帮助答主解决学习了SQL之后可以做什么的问题。
实战如何分析用户？
——用SQL做一份数据分析报告涉及什么哪些知识点？
在工作中，每个数据分析师都离不开做数据分析报告，而一份可落地的报告更是要求灵活地应用工具及理论知识。接下来，我们从工具应用的角度，看看如何用SQL做一份完整的数据分析报告。
数据导入
- 新建数据库
- 用优秀的数据库管理工具Navicat 连接数据库
- 通过Navicat 将数据（如Excel、SQL脚本等格式）导入数据库
数据清洗
数据清洗的目的是为了将数据按照业务分析需求，剔除异常值、离群值，使分析结果更准确反映业务实际。
常见的步骤如下：
- 是否存在空值：
WHERE `字段名` is null
- 是否存在重复数据：
通过GROUP BY关键字实现
SELECT COUNT(*) FROM 表名 GROUP BY 字段名 HAVING COUNT(*) >1
- 是否存在业务定义以外的数据：
如需要分析华南区域数据，而数据中出现华北数据
数据格式化
这一步是要根据后续分析需求，调整表格结构、数据格式等，如出于数据存放原因，拿到的数据表格可能是一维表，不满足分析需求，需要将其调整为二维表。
常见的步骤如下：
- 时间函数：
如将「时间戳」格式化为日期、时间、月份、周几（常见于周分析）等，可通过「FROM_UNIXTIME」「DATE_FORMAT」等函数实现
- 行列互换：
如解决上述的一维表转为二维表的问题，可通过关键字「CASE WHEN」实现
- 字段的拆分与合并：
如将收货地址字段拆为省、市、镇等字段，可通过「CONCAT」「LEFT」「RIGHT」「SUBSTRING」等函数实现
整体分析
在开始真正的分析之前，需要进行探索性数据分析(Exploratory Data Analysis，EDA)，也就是对现有数据进行整体分析，对现状有大体的了解。更重要的是，通过整体分析，找出业务运营存在的问题，进而提出业务目标，展开后续的深度分析。
常见的步骤如下：
- 漏斗分析：
如海盗模型AARRR，阿里营销模型AIPL等，通过简单的「COUNT」函数，直接数就可实现
建立视图
面对复杂的业务分析，SQL语句也会变得复杂，往往需要不断嵌套。为了减少分析时语句的复杂性、避免重复执行相同语句，可以采用新建视图的方式，将重复性高的语句固定为视图，再在此基础上进行复杂查询。
新建视图：
CREATE VIEW 视图名 AS SELECT..
用户分析
从整体分析中，明确业务问题、目标后，便可开始进行用户分析。根据分析目的的不同，采用不同的分析方法，而常见的分析方法如下：
「人货场」分析
「复购」分析，核心问题在于如何计算“复购”：
用「窗口函数+DENSE_RANK()」统计每个订单是该用户的第几次消费，命名为'N_CONSUME'
第一次消费即为用户“首购订单”，大于等于第二次消费的订单则为“复购订单“
针对复购订单进行统计，即可进行复购分析
- 「RFM模型」分析，核心问题在于如何定义阈值及人群划分：
通过【窗口函数】可计算出每个用户的RFM值：
R：每个用户最后消费日期，与分析日期相减的天数即为R
F：通过复购分析中得出的N_CONSUME，计算最大消费次数即为F
M：简单地SUM用户所有消费金额，即为M
阈值：可通过计算所有用户的R,F,M平均值获得
所有用户的RFM值与阈值比较，通过「CASE WHEN」转为 '高'、'低' 两个值
根据RFM高低值通过「CASE WHEN」将所有用户划分到八个人群中
总结建议
根据前文进行的分析，即可总结得出的结论。此外，在业务分析中，更重要的是如何结合业务场景来给出可落地的业务建议。