数据分析面试必备：SQL笔试题实战解析与练习

常见的SQL笔试题（持续更新）

在MySQLScore：安装与入门、简单查询、汇总分析、复杂查询、多表查询中练习SQL入门技能。
这次我们整理了SQL面试中最常见的笔试题，这篇文章会持续更新。
文章分为两部分：常见笔试题型分析和牛客网SQL实用题SQL优化与练习。
第一部分主要分析笔试常见题型，包括基础题和高级题。
初级查询包括单表查询、查询条件、结果排序、有界集、case表达式、分组汇总等。
高级查询包括多表连接、集合操作、子查询、窗口函数等。
其中包括EXISTS运算符用于快速测试行是否存在，提高查询性能。
第二部分提供了牛客网的实用SQL练习。
问题包括查找最新的员工信息、员工入职时间倒数第三的员工信息、各部门负责人的薪资明细、所属部门员工信息、所有员工信息（包括未所属部门员工）、员工入职薪资状况等。
15倍以上、员工当前薪资、部门主管当前薪资、非经理、员工现任经理、薪资最高员工信息部门中特定职称对应的员工人数、员工信息（emp_no为奇数，姓氏不是Mary）、当前薪资对应的平均薪资、薪资第二高的员工信息（无需要排序）以及第二高员工的排名信息（不允许排序）。
这些题涵盖了SQL的几个知识点，比如：如关联子查询、多表查询、分组、排序、窗口函数等。
通过练习和理解以上问题，可以系统掌握SQL使用技巧和常见面试题。
不断更新更多问题，确保学习者完全掌握SQL技能。

【数据分析面试】大厂高频SQL笔试题（三）

数据分析SQL笔试题系列第三篇来了！如果你还没有看过以往笔试题的文章，可以看看历史文章。
无论你是应届毕业生，还是想转行数据分析的新手玩家，只要你想进入数据分析行业，就无法逃脱数据分析面试的考验。
这里最重要、最关键的关卡就是SQL笔试。
不过不用担心，结合笔者6+年的工作和面试经验，系统全面地整理了数据分析面试中经常出现的、各大厂商的SQL笔试题。
我学习了这些笔试题的常见套路和解法，把这些题都过一遍。
接下来你应该能够顺利通过笔试并拿到offer！SQL笔试不仅考验代码的熟练程度，还考验对业务的理解。
只有了解业务背景和逻辑，才能更快、更准确地给出答案。
本文选取PDD业务笔试题来测试一定业务背景下的SQL能力。
快来看看这些问题你都知道吗？某购物APP最近推出了新功能。
用户登录后即可跳转到大轮播抽奖。
抽奖获得的奖品可以抵消购物成本，从而培养用户使用应用程序的习惯。
有一个用户行为表user_log。
主要字段如下。
它记录了用户在应用程序上的所有行为日志，即谁user_id在什么时间event_time执行了什么操作event_id。
需求：1、计算每天应用的访问人数以每人每天的平均操作次数。
2、统计每天签到参与抽奖的用户数量。
注意，签到和抽奖活动必须是相邻的（签到和抽奖活动对应的event_id分别为‘register’和‘gift’）。
思路：第一个问题比较简单。
计算每天访问该应用的人数。
由于登录访问应用的用户会在表中生成相应的行为日志，因此每天的访问人数只需按每天的用户数去重即可。
平均每天的访客数是动作数的计算，因为一次动作会产生一条记录，所以每人的动作数就是所有记录的数量除以访客总数。
第二题升级了难度。
虽然也统计用户数，但是却增加了限制：登录后需要大轮抽奖，并且两个动作必须相邻。
这时，我们可以使用窗口函数的位移函数lead()over()来实现这一点。
领先者可以取得当前记录的下一条记录。
如果我们将每个用户user_id按照行为时间event_time进行升序排列，就可以得到一个用户的连续行为记录，可以使用lead()来获取下一条记录，从而获取下一条记录当前记录。
通过过滤连续的两个行为，就可以计算出满足该条件的用户数量。
为了增加某店的营业额，运营部近期推出了多项运营活动。
用户参与活动后可以获得无限量优惠券，鼓励用户下单。
但每个用户只能参与一项活动，不能同时参与多项活动。
有订单表orders和活动登记表act_join，分别记录用户的订单明细和用户的活动明细。
具体字段如下：订单表orders，大致字段为（user_id‘用户编号’，order_id‘订单编号’，order_sales‘订单金额’，order_time‘订单时间’）。
活动报名表act_join，大概字段为(act_id'活动号',user_id'报名用户',join_time'报名时间')需求：1.统计每个活动结束后所有报名的用户的总订单金额和产生的总订单登记。
数字。
（每个用户仅限注册一次活动，用户注册后生成的订单默认为参与该活动的订单）。
2、统计从每项活动开始到当日（数据统计日）每天产生的平均订单数。
活动开始时间定义为用户最早注册的时间。
思路：第一题是计算订单总金额和订单总数。
这两个指标比较简单。
Sum(order_sales)和count(order_id)就足够了，但关键在于资质，是用户注册每个活动后的汇总。
您必须已注册参加活动，并且必须在活动开始后收集数据。
您可以连接订单表orders和注册表act_join，并限制订单时间大于或等于事件开始时间。
问题2与问题1类似，也是用户注册后下的订单，但有一些额外的限制：它必须小于或等于计算日期，即系统时间now()时程序正在运行。
在此基础上计算订单总数。
，除以活动进行的天数，就是该活动每天下的平均订单数。
注：这里使用窗口函数计算每个活动的开始时间，然后通过where条件加入订单表满足上述条件。
当然，这只是解决问题的一种方法。
您还可以尝试许多其他解决方案。
通过上面两个实际的业务场景，不仅考验了SQL编能力，更重要的是考验了大家对业务场景的理解能力。
如果不能理解业务场景，SQL代码就很难写。
相反，如果业务场景场景非常熟悉，代码也比较简单。
所以我们在练习SQL的时候一定要结合业务场景来练习。
只有这样，才更贴近实际的业务场景，我们才能够在笔试中脱颖而出，脱颖而出！