2026年数据分析师（校招）高频面试题及解答

数据分析师（校招）高频面试题

精选100道·含详细解答

面试前刷一遍，心中更有底

★表示出题频率：★★★较高★★★★很高★★★★★最高

一、基础理论与统计学知识（20道）

1.介绍一下中心极限定理，以及它在数据抽样中的实际意义？★★★★★（考察统计学底层

基础）

2.什么是假设检验？请简述P值（P-value）的具体含义。★★★★★（考察假设检验基本原

理）

3.第一类错误和第二类错误分别代表什么？在业务中哪种错误更难以接受？★★★★★（考

察统计概念与业务结合）

4.简述方差、标准差和协方差的区别与联系。★★★★★（考察基础统计量理解）

5.正态分布有哪些重要特征？在实际业务数据中如果不服从正态分布如何处理？★★★★★

（考察数据分布特征）

6.什么是置信区间？如何解释“95%的置信区间”？★★★★★（考察参数估计概念）

7.常见的概率分布有哪些？请分别举例说明其适用场景（如泊松分布、二项分布）。

★★★★（考察概率分布知识）

8.贝叶斯定理的核心思想是什么？在数据分析中有哪些应用场景？★★★★（考察贝叶斯理

论应用）

9.什么是相关性与因果性？如何通过数据验证因果关系？★★★★★（考察因果推断思维）

10.辛普森悖论是什么？请举一个可能在日常业务中发生的例子。★★★★★（考察经典数据

悖论）

11.什么是大数定律？它与中心极限定理有何区别？★★★★★（考察核心概率定律）

12.解释什么是过拟合与欠拟合，以及如何防止过拟合？★★★★★（考察机器学习基础）

13.常见的分类模型有哪些？请简述逻辑回归（LogisticRegression）的原理。★★★★★

（考察基础算法原理）

14.决策树的分裂依据有哪些？（如信息增益、基尼系数等）★★★★（考察树模型基础）

15.K-Means聚类的K值如何选择？该算法对异常值敏感吗？★★★★（考察聚类算法理解）

16.评价分类模型好坏的指标有哪些？（如准确率、精确率、召回率、F1）★★★★★（考察

模型评估指标）

17.ROC曲线和PR曲线有什么区别？数据不平衡时更倾向于看哪个？★★★★（考察高阶模

型评估）

18.线性回归的前提假设有哪些？如果违背了这些假设会怎样？★★★★（考察回归模型假

设）

19.简述PCA（主成分分析）的降维原理及适用场景。★★★（考察降维算法知识）

20.遇到缺失值和异常值，你在统计学上通常有哪些处理策略？★★★★★（考察数据清洗理

论）

二、SQL与数据库基础（20道）

21.SQL中WHERE和HAVING的区别是什么？执行顺序是怎样的？★★★★★（考察SQL基础

语法）

22.请详细说明SQL查询语句（SELECT）中各关键字的执行顺序。★★★★★（考察SQL底

层逻辑）

23.各种JOIN操作（INNER,LEFT,RIGHT,FULL）有什么区别？★★★★★（考察表连接逻

辑）

24.什么是窗口函数？Row_Number()、Rank()和Dense_Rank()的区别是什么？★★★★★

（考察高阶窗口函数）

25.如何用SQL实现用户留存率的计算？（例如次日留存、7日留存）★★★★★（考察核心业

务SQL实现）

26.如何用SQL找出连续登录N天以上的活跃用户？★★★★★（考察复杂逻辑SQL能力）

27.如何用SQL求解单日累计最高在线人数？★★★★（考察特定场景SQL应用）

28.COUNT(*)、COUNT(1)和COUNT(列名)的区别及性能差异是什么？★★★★（考察聚合函

数理解）

29.UNION和UNIONALL的区别是什么？哪一个性能更好？★★★★★（考察结果集合并语

法）

30.什么是数据倾斜？在使用SQL处理大数据时如何解决数据倾斜问题？★★★★（考察大数

据处理概念）

31.EXISTS和IN有什么区别？在什么情况下使用EXISTS效率更高？★★★★（考察子查询性

能优化）

32.SQL中如何进行行转列、列转行操作？★★★★（考察数据格式转换）

33.解释一下数据库中主键、外键和唯一索引的区别。★★★★★（考察数据库约束概念）

34.数据库索引的底层数据结构通常是什么？为什么不用哈希表？★★★★（考察索引底层原

理）

35.什么是事务？事务的ACID特性具体指什么？★★★★★（考察数据库事务基础）

36.慢SQL查询通常有哪些优化思路？★★★★★（考察SQL优化能力）

37.如何用SQL实现百分位数（如P90，P99）的计算？★★★★★（考察统计学指标SQL

化）

38.HiveSQL和MySQL在语法和执行机制上有什么主要区别？★★★★★（考察不同数据库差

异）

39.如何用SQL计算用户的会话（Session）数量？（规定间隔超过30分钟视为新会话）

★★★★（考察复杂业务场景抽象）

40.在海量数据去重场景下，如果不用DISTINCT，还有哪些替代方案？★★★（考察大数据

优化思维）

三、Python与数据处理能力（15道）

41.Pandas中Merge、Join和Concat的区别分别是什么？★★★★★（考察Pandas基础操

作）

42.如何使用Python进行数据的分组聚合操作？（GroupBy的内部机制）★★★★★（考察数

据聚合能力）

43.Python中列表（List）和元组（Tuple）的区别是什么？★★★★★（考察Python基础数据

结构）

44.解释字典（Dict）的底层实现原理，为什么它的查询速度很快？★★★★★（考察哈希表

原理）

45.简述Pandas中Apply、Map和Applymap函数的区别及适用场景。★★★★★（考察

Pandas高效计算）

46.Python中如何高效处理达到数GB级别的超大CSV文件？★★★★（考察大数据量处理技

巧）

47.Numpy的广播机制（Broadcasting）是什么？有什么作用？★★★★★（考察向量化计算

原理）

48.什么是生成器（Generator）和迭代器（Iterator）？如何使用它们节省内存？★★★★（考

察Python高级特性）

49.在Python中遇到多重嵌套的JSON数据，通常如何解析并扁平化提取？★★★★★（考察复

杂数据解析能力）

50.简述Python中的深拷贝和浅拷贝的区别。★★★★★（考察对象引用机制）

51.如何用Python实现针对时序数据的滑动窗口计算（如7天移动平均）？★★★★（考察时

序数据处理）

52.面向对象编程中的继承和多态在数据分析脚本编写中有什么实际用处？★★★（考察编程

思维）

53.用Python进行正则表达式匹配时，贪婪模式和非贪婪模式有什么区别？★★★（考察文本

处理能力）

54.介绍常用的Python数据可视化库（如Matplotlib/Seaborn/Pyecharts），它们各有什么优缺

点？★★★★（考察数据可视化工具应用）

55.如果要在Python脚本中捕捉和处理异常（Exception），应该遵循什么原则？★★★★（考

察代码健壮性意识）

四、业务洞察与指标体系构建（15道）

56.如果让你为一个全新的短视频APP搭建核心指标体系，你会如何设计？★★★★★（考察

全局业务拆解能力）

57.常见的北极星指标（OSM模型）和用户生命周期（AARRR模型）分别是什么？

★★★★★（考察经典分析模型框架）

58.某电商平台近期DAU（日活用户）突然下降20%，请阐述你的排查思路。★★★★★（考

察异常问题拆解与归因）

59.GMV（商品交易总额）不及预期，你会从哪些维度去定位问题？★★★★★（考察业务归

因分析逻辑）

60.什么是用户画像（Persona）？构建用户标签体系的基础步骤有哪些？★★★★★（考察

用户研究方法论）

61.如果要分析一个拉新活动的ROI，你需要收集并计算哪些具体数据指标？★★★★★（考

察活动效果评估指标）

62.如何科学地界定“流失用户”？（如时间窗口的确定依据）★★★★★（考察流失预警分

析）

63.RFM模型包含哪三个维度？在用户精细化运营中如何实际落地应用？★★★★★（考察用

户分层模型）

64.分析转化漏斗时，如果发现某一步骤转化率极低，你会如何进一步下钻分析？★★★★

（考察漏斗分析深度）

65.什么是同型群组分析（CohortAnalysis）？它在评估产品改版时有什么优势？★★★★

（考察群组分析方法）

66.竞争对手上线了一个新功能，业务方想评估对我们产品的影响，你怎么做？★★★★（考

察竞品数据分析思维）

67.如何通过数据分析识别平台上的“羊毛党”或作弊用户？★★★★（考察风控及异常洞察）

68.在设计一个外卖骑手派单效率的监控看板时，你会包含哪些核心模块？★★★★（考察BI

看板设计逻辑）

69.“用户停留时长”变长一定是好事吗？请结合不同业务场景说明。★★★（考察业务指标辩

证思考）

70.如果业务方要求你做一个无法用数据量化的分析需求，你该如何沟通与拆解？★★★（考

察业务沟通与转化能力）

五、A/B测试与实验设计（10道）

71.什么是A/B测试？请简述一个完整的A/B测试流程包含哪些环节。★★★★★（考察AB测

试核心流程）

72.在A/B测试中，如何科学地确定所需的最小样本量？★★★★★（考察实验设计样本估

算）

73.A/B测试中的AA测试（A/ATest）有什么作用？什么时候必须做AA测试？★★★★★（考

察实验严谨性验证）

74.实验结果的P值小于0.05，是否意味着新策略可以直接全量上线？为什么？★★★★★

（考察实验结果科学解读）

75.如果A/B测试中实验组和对照组存在明显的互相干扰（网络效应），该如何解决？

★★★★★（考察复杂实验场景应对）

76.如何应对实验期间的辛普森悖论？（如整体实验有效，但细分群体均无效）★★★★★

（考察实验异常数据分析）

77.对于低频且转化周期长的业务（如房产交易），如何进行A/B测试评估？★★★★（考察

非标准场景实验设计）

78.多重检验问题（MultipleTesting）是什么？在实验分析中应如何校正？★★★★（考察高

级统计假设检验）

79.实验不仅没有正向收益，反而导致核心指标下降，你的分析报告应该怎么写？★★★★

（考察实验复盘思维）

80.如果业务方以“开发成本高”为由拒绝做A/B测试，你还有哪些替代方案评估效果？★★★

（考察因果推断替代方案）

六、项目实习经历深度挖掘（10道）

81.请详细描述你在实习/项目中遇到的最难处理的数据问题，以及你是如何解决的。

★★★★★（考察实际问题解决能力）

82.你简历中提到的这段数据分析经历，最终给业务带来了什么实质性改变？★★★★★（考

察项目业务价值导向）

83.在你的过往项目中，是如何保证基础数据的准确性和一致性的？★★★★★（考察数据质

量把控意识）

84.回顾你做过的某个核心数据分析报告，如果是现在重新做，会有哪些改进空间？

★★★★★（考察复盘与迭代思维）

85.在团队合作项目中，如果你的分析结论与业务方的直觉相违背，你是如何处理的？

★★★★★（考察跨部门沟通与说服力）

86.请具体说明你在项目中使用的某个关键模型（或公式），为什么要选它而不是其他方法？

★★★★（考察技术选型合理性）

87.你的项目中提到了自动化报表搭建，请说明你是如何优化其运行效率的。★★★★（考察

工程实现与优化能力）

88.在没有现成数据可用的项目初期，你是如何通过埋点或外部渠道获取所需数据的？

★★★★（考察数据获取主动性）

89.如果面试官认为你简历中的某个指标提升并不全是你的功劳，你怎么自证？★★★★★

（考察客观归因与逻辑严谨性）

90.描述一次你在数据探索时走过“弯路”的经历，最终是如何拉回正轨的。★★★★（考察抗

挫折与纠偏能力）

七、逻辑思维与开放性问题（5道）

91.如果让你估算你所在城市一天消耗的咖啡杯数（费米问题），你的拆解逻辑是什么？

★★★★★（考察逻辑拆解与假设能力）

92.假如一家餐厅的收入一直在涨，但利润却在跌，请画出一棵逻辑树进行归因分析。

★★★★★（考察MECE原则与结构化思维）

93.为什么“冰激凌的销量”和“溺水身亡的人数”呈现高度正相关？★★★★★（考察混杂变量识

别与常识逻辑）

94.如果有1000瓶水，其中1瓶有毒，小白鼠喝了毒水后24小时发作，要求24小时内找出毒

水，最少需要几只小白鼠？★★★★（考察二进制算法思维）

95.在没有任何其他工具的情况下，如何利用数据分析思维判定一枚硬币是否均匀？★★★

（考察统计思维发散）

八、综合素质与职业规划（5道）

96.为什么选择做数据分析师？你认为应届生从事这个岗位最大的优势和劣势分别是什么？

★★★★★（考察求职动机与自我认知）

97.你认为“数据研发”、“数据分析”与“算法工程师”三者之间的核心边界在哪里？★★★★★

（考察行业及岗位认知深度）

98.面对突如其来的大量且紧急的数据取数需求，你如何进行优先级排序和时间管理？

★★★★★（考察抗压能力与任务管理）

99.请分享你近期学习的一项与数据分析相关的新技术或新理论，并说明你的学习途径。

★★★★★（考察持续学习驱动力）

100.你对自己未来3到5年的职业规划是怎样的？期待在公司获得怎样的成长？★★★★★（考

察职业规划与稳定性）

数据分析师（校招）高频面试题解答

一、基础理论与统计学知识（20道）

本章节主要考察应届生在统计学与概率论方面的扎实度，这是数据分析师的内功。

重点评估大家是否能将书本上的数理理论转化为解决实际业务问题的底层业务思

维。

Q1：介绍一下中心极限定理，以及它在数据抽样中的实际意义？

答题分析：

考察频率：★★★★★

考察点：考察统计学底层基础

答题思路：先用白话解释定理核心（大样本随机抽样均值趋于正态分布），再结合真实的

业务场景（如计算海量数据的成本问题、AB测试的实验推断）说明其作为抽样理论基石

的价值。

避坑点：切忌背诵枯燥的数学公式，不能只提“大于30个样本”，缺乏业务场景落地的延

伸，容易暴露出脱离实际的“应试感”。

参考回答：

中心极限定理的核心是，无论总体的原始数据呈现什么分布，哪怕非常不规则，只

要进行大量且独立的随机抽样，这些样本均值的分布就会逐渐趋近于正态分布。通

常统计学上认为样本量大于等于30时，这种特征就很明显。

在真实的业务场景里，这个定理是我们做数据抽样分析的理论基石。很多时候我们

面临海量数据，比如要评估几千万用户的某个消费特征，直接拉全量数据去计算，

耗时且占用算力大。

借助中心极限定理，我们可以从大盘随机抽取一小批代表性样本。因为知道样本均

值服从正态分布，就能用这批抽样数据去预估整体用户的真实情况，大幅降低数据

处理成本。

另一个典型场景是业务里常做的AB实验。评估新功能效果时，通常只圈选小比例用

户测试。基于这个定理，我们才能踏实地去计算P值和置信区间，科学判断新策略

是否真的带来了收益，避免被偶然波动误导。

Q2：什么是假设检验？请简述P值（P-value）的具体含义。

答题分析：

考察频率：★★★★★

考察点：考察假设检验基本原理

答题思路：明确假设检验的推断逻辑（小概率反证法），用口语化解释P值的本质（原假

设下极端情况发生的概率），最后点明其在评估业务动作有效性中的作用。

避坑点：把P值错误解释为“原假设为真的概率”或“犯错的概率”，这是统计学面试中最常见

的硬伤。

参考回答：

假设检验本质上是一种利用样本数据来推断总体特征的统计方法。我们平时做业务

决策，往往很难拿到完美的全量数据，这时候就会先提出一个关于总体分布的假

设，也就是原假设，然后根据抽样得来的数据去计算统计量，看看有没有足够的证

据去拒绝这个原假设。

关于P值，大家常常觉得它有点绕。其实把它放在实际业务里就好懂了。P值就是在

原假设成立的前提下，我们观察到当前这批样本数据，甚至比当前数据更极端情况

出现的概率。

换句接地气的话来说，P值衡量的是我们的实验结果到底是不是因为巧合导致的。

如果计算出来的P值特别小，比如小于约定的0.05，就说明这种结果纯靠运气发生

的概率极低。

这时候我们就有底气推翻原假设，认定我们的新策略或者新功能是真的产生了实质

性效果，而不仅仅是数据的随机波动。这也是我们在做产品版本对比实验时，判断

指标变化是否显著的核心依据。

Q3：第一类错误和第二类错误分别代表什么？在业务中哪种错误更难以接受？

答题分析：

考察频率：★★★★★

考察点：考察统计概念与业务结合

答题思路：清晰定义“弃真”（假阳）和“存伪”（假阴），通过生动的业务比喻（错杀好人

vs漏掉坏人）阐释，并根据不同业务属性辩证讨论容忍度。

避坑点：不要死记硬背“Alpha和Beta”，遇到“哪个更难接受”时给出非黑即白的绝对答案，

忽略了具体业务周期的权衡。

参考回答：

在做假设检验时，第一类错误可以理解为“弃真”，也就是原假设本来是对的，但我

们错误地拒绝了它。对应到业务里，就像是我们上线了一个新功能，它其实毫无效

果，但测试数据碰巧很好，导致我们误以为功能有效并且推给了用户，这是典型的

假阳性。

第二类错误叫作“存伪”，意思是原假设是错的，但我们没能拒绝它。放在业务场景

看，好比我们费很大劲研发出能提升转化率的好策略，但在测试时由于数据波动没

发现效果，错失了这个好策略，属于假阴性。

至于哪种错误更难接受，这完全取决于具体的业务阶段和场景。

如果是为了求稳的金融风控业务，第一类错误是很难容忍的，把坏人错当成好人放

进来会导致直接损失，这时候会把显著性水平卡得非常严。但如果是探索期的新产

品试错，为了不错过任何潜在的增长机会，我们可能就更害怕犯第二类错误。

Q4：简述方差、标准差和协方差的区别与联系。

答题分析：

考察频率：★★★★★

考察点：考察基础统计量理解

答题思路：依次讲清楚三个概念的核心作用，重点点出标准差解决方差量纲问题的意义，

以及协方差从单变量向双变量关系延伸的价值。

避坑点：只罗列数学算式，没有讲透“量纲”的实际沟通痛点，以及未能指出协方差无法准

确衡量相关程度（未标准化）的局限性。

参考回答：

方差、标准差和协方差都是用来衡量数据分布情况的统计量，但在具体的应用视角

上有一些差别。

方差衡量的是单个变量里所有数据点偏离平均值的程度，它是各个数据与均值差值

的平方和的平均数。不过方差的计算结果带有了平方的量纲，比如我们在分析用户

的月均消费金额，算出来的方差单位是“元的平方”，这在业务报告里很难直观解

释。

为了解决这个量纲理解的问题，我们给方差开个根号，这就得到了标准差。标准差

的单位和原始数据保持一致，能非常直观地告诉业务同学，咱们用户的消费额大概

在一个什么跨度范围内波动，平时做数据离群值检测时也最常用。

前两个指标都在研究单个变量自己是怎么波动的，而协方差则是研究两个变量之间

是怎么联动变化的。如果两个变量的协方差是正数，说明它们有同向变化的趋势；

如果是负数则是反向变化。我们在探究用户特征关系时，它是很好的前置参考指

标。

Q5：正态分布有哪些重要特征？在实际业务数据中如果不服从正态分布如何处

理？

答题分析：

考察频率：★★★★★

考察点：考察数据分布特征

答题思路：列出正态分布的核心特征（钟形、对称、3σ法则），针对不服从的情况提供

常用的处理手段（如对数变换、使用非参数检验），展现解决实际脏数据的能力。

避坑点：遇到长尾数据强行丢弃“异常值”以拟合正态分布，或者不知道在不满足正态假设

时还有非参数检验这条退路。

参考回答：

正态分布在统计学里的特征很鲜明，它是一条经典的钟形曲线，以均值为中心左右

对称，均值、中位数和众数都重合在一个点上。我们常说的3Sigma法则也是它的

特征，也就是绝大多数的数据都会落在距离均值三个标准差的范围之内。

不过在真实的互联网业务里，像用户的消费金额、停留时长这些指标，往往并不完

美服从正态分布，通常呈现出明显的右偏长尾特征，一小部分土豪用户拉高了均

值。

遇到这种情况，我会看具体的分析诉求来处理。如果数据偏态很严重，最常规的做

法是做对数变换或者Box-Cox变换，把数据强制拉平稳，让它更接近正态分布，这

样后续套用线性模型会更准确。

如果不想破坏原始数据结构，我就会放弃依赖正态假设的方法，转而去使用非参数

检验，比如用曼-惠特尼U检验来做两组样本的显著性对比，这样能更好地还原真实

的业务波动情况。

Q6：什么是置信区间？如何解释“95%的置信区间”？

答题分析：

考察频率：★★★★★

考察点：考察参数估计概念

答题思路：说明点估计与区间估计的区别，重点准确解释“95%”的概率含义指的是抽样方

法的可靠性，而不是特定区间包含总体参数的概率。

避坑点：常犯的概念错误是说成“总体均值有95%的概率落在这个区间内”，这种静态解释

在严谨的面试官眼中是大忌。

参考回答：

我们在业务中预估某个总体指标时，往往给出一个确切的单一数字不够靠谱，这时

候就需要用到置信区间。它本质上是一个区间估计，就是用样本数据计算出一个下

限和上限的范围，并且附带一个可信程度，用来涵盖我们关心的总体真实参数。

对于“95%的置信区间”，很多同学容易误解成总体真实值有95%的概率落在这个算

出来的区间里。其实总体真实值是一个固定的客观存在，它要么在这个区间，要么

不在，不存在概率问题。

正确的理解角度应该放在抽样这个动作上。它的意思是，如果我们用完全相同的方

法去随机抽样一百次，并且算出一百个这样的置信区间。

在这构建出来的一百个区间里，大概会有九十五个能够真正包含那个未知的总体真

实值。在日常写数据报告的时候，提供这个区间，主要是为了给业务方一个合理的

波动预期，让大家知道指标在哪个范围内浮动是正常的。

Q7：常见的概率分布有哪些？请分别举例说明其适用场景（如泊松分布、二项

分布）。

答题分析：

考察频率：★★★★

考察点：考察概率分布知识

答题思路：分类列举离散型和连续型分布，必须紧扣日常业务场景进行举例（例如客服接

线、用户点击转化等），体现对理论落地业务的直觉。

避坑点：举的例子过于学术（如抛硬币、掷骰子），应尽量使用实际互联网场景或运营案

例来展现职业感。

参考回答：

日常分析里最常见的概率分布可以分成离散型和连续型两大类。离散型里最典型的

就是二项分布和泊松分布，连续型主要就是正态分布。

二项分布主要用来描述只有两种可能结果的重复实验。比如我们在做广告投放时，

统计1000个用户曝光后，最终点击或者不点击的人数分布，这就非常契合二项分布

的特征，它是算转化率概率的基础。

泊松分布则用来描述在一段固定时间或者空间内，某种稀有事件发生的次数。在咱

们的业务场景里，比如预测每天下午两点到三点，客服中心会接到多少个投诉电

话，或者网站在一小时内会遇到多少次服务器崩溃，用泊松分布来建模就非常贴

切。

正态分布就不多说了，它无处不在。像业务里连续变化的数据，比如员工的绩效打

分分布、某种标准生产零件的尺寸误差，只要受到很多微小独立因素叠加影响，通

常都会呈现正态分布的规律。

Q8：贝叶斯定理的核心思想是什么？在数据分析中有哪些应用场景？

答题分析：

考察频率：★★★★

考察点：考察贝叶斯理论应用

答题思路：解释先验概率向后验概率更新的思维过程（根据新证据调整认知），列举典型

的应用场景如垃圾邮件过滤、风控判别等。

避坑点：只列出公式P(A|B)=P(B|A)*P(A)/P(B)，缺乏对“更新认知”这一哲学思想的

提炼，让人感觉是死读书。

参考回答：

贝叶斯定理的核心思想，其实就是一种“根据新证据来不断更新认知”的逻辑。它和

传统统计学不太一样，它允许我们一开始先带着一个经验判断，也就是先验概率。

当观测到新的数据或者发生新事件后，我们再把这个新信息融合进去，计算出一个

更准确的后验概率。

这种思维在很多业务场景里都能发挥巨大作用。最经典的就是反作弊和风控模型里

的应用。

比如判断一个新注册账号是不是羊毛党。刚开始我们可能只知道大盘里大概有百分

之五是作弊账号，这是先验。但当这个账号快速绑定了三张虚拟手机卡，这就是新

引入的证据。利用贝叶斯思想，我们会迅速更新概率估算，得出这个账号是羊毛党

的概率可能飙升到了百分之八十以上。

另外像我们平时的推荐系统预估点击率，或者朴素贝叶斯分类器用来拦截垃圾邮

件、做文本的情感判断，底层依靠的都是这套利用新特征不断修正概率结果的思

想。

Q9：什么是相关性与因果性？如何通过数据验证因果关系？

答题分析：

考察频率：★★★★★

考察点：考察因果推断思维

答题思路：明确指出“相关不等于因果”（可能存在混杂因子）。介绍验证因果的核心手段

（黄金标准是随机对照实验ABTest，退而求其次是双重差分、断点回归等观测数据方

法）。

避坑点：以为有了回归模型或者高相关系数就能断定因果，忽略了内生性和遗漏变量的干

扰。

参考回答：

相关性只是说明两个变量在趋势上有关联，比如一起变大或一增一减，但这种联动

可能是巧合，也可能是受第三方变量影响造成的。而因果性是非常严苛的，必须明

确是变量A的变化导致了变量B的发生，也就是存在明确的前后动作逻辑。

平时在业务看数时，相关不等于因果是很容易踩坑的地方。比如夏天雪糕销量和溺

水人数同时上升，它们高度相关，但本质原因都是天气变热这个第三方因素，互为

因果肯定不成立。

如果要在数据上严谨验证因果关系，最黄金的标准就是做AB测试。通过完全随机分

流控制住所有外部干扰，只有我们施加的策略变量不同，这时候指标的差异才能确

认为因果。

但在很多客观条件下没法做实验，那我们就会采用准实验的设计方法去验证。比如

使用双重差分法，寻找在时间前后受到政策冲击的干预组和没有受冲击的对照组，

通过抹平原有差异来剥离出因果净效应。

Q10：辛普森悖论是什么？请举一个可能在日常业务中发生的例子。

答题分析：

考察频率：★★★★★

考察点：考察经典数据悖论

答题思路：解释在分组和整体聚合时得出截然相反结论的现象。需自己构思一个清晰的业

务场景（如转化率、留存率分析），强调下钻细分维度的重要性。

避坑点：举例不够直观或者逻辑算不平，没有点出造成悖论的根源往往是“各组样本量基

数分布极度不均”。

参考回答：

辛普森悖论指的是，在分析数据时，如果把数据拆分成几个细分群体看，得出了某

一种结论；但如果把这些群体全部合拢看整体大盘，却得出了完全相反的结论。这

种情况往往是因为不同群组之间的样本基数大小差异极其悬殊导致的。

在日常业务复盘里，这种陷阱很容易出现。假设我们对比新旧两个版本的首页转化

率，从整体上看，新版本的总转化率甚至比老版本还跌了。业务方可能直接要求回

滚。

但如果我们按新老用户拆开来看，会发现新版本中，新用户的转化率是提升的，老

用户的转化率也是提升的。

之所以整体会下跌，是因为当天正好有一波大规模渠道投放，引流进来了海量转化

极低的新用户，把新版本的样本权重给彻底拉偏了。面对这种悖论，我们做分析就

必须要具备下钻拆解的意识，找到那些隐藏在背后的混杂变量，才能还原业务真

相。

Q11：什么是大数定律？它与中心极限定理有何区别？

答题分析：

考察频率：★★★★★

考察点：考察核心概率定律

答题思路：大数定律讲的是“收敛性”（样本均值趋近总体均值），中心极限定理讲的是“分

布形态”（样本均值分布趋近正态分布）。两者相辅相成但侧重点不同。

避坑点：把两者混为一谈，或者解释大数定律时说成了“抛硬币次数越多，正反面次数越

绝对相等”（其实是比例相等，不是绝对差值缩小）。

参考回答：

大数定律的核心意思其实很直观，当我们做一项随机试验，试验的次数越来越多、

样本量越来越大的时候，这些样本计算出来的算术平均值，就会无限逼近总体真实

的期望值。就像我们不断抛硬币，抛个几万次，正面向上的频率就会非常稳定地停

留在百分之五十。

很多时候大家会把它和中心极限定理搞混，其实它们的侧重点完全不一样。

大数定律探讨的是一个“数值”的收敛问题，它告诉我们只要数据够多，样本均值就

是靠谱的，这就给了我们用小样本数据去评估大盘指标均值的信心。

而中心极限定理探讨的是“分布形态”的问题。它不光关心均值准不准，更在乎这些

不同样本均值画出来的图是什么形状。它告诉我们这个形态会呈现完美的正态分

布，从而给我们做假设检验、划设置信区间提供了明确的数学依据。

Q12：解释什么是过拟合与欠拟合，以及如何防止过拟合？

答题分析：

考察频率：★★★★★

考察点：考察机器学习基础

答题思路：用通俗的比喻解释过拟合（死记硬背）和欠拟合（没学懂）。重点分点列出防

过拟合的实际手段（增加数据、正则化、早停、剪枝、Dropout等）。

避坑点：只谈概念不提解决思路，或者列举防过拟合策略时脱离具体算法种类泛泛而谈。

参考回答：

过拟合和欠拟合是我们在训练模型时最常遇到的两种异常状态。如果把训练模型比

作学生备考，欠拟合就像是学生底子太差，连最基础的课本知识都没学懂，导致在

训练集和测试集上的表现都很烂，通常是因为模型太简单或者特征没提取够。

过拟合则像是学生在死记硬背，把练习册上的原题连同错别字都背下来了。这就导

致模型在训练集里表现惊艳，但一换到未知的测试集上直接崩溃，泛化能力很差。

在实际建模时，防止过拟合的思路主要有这几个方面。

最根本的办法是想办法扩充清洗数据，增加样本量。如果是算法层面，我们可以加

入L1或L2正则化惩罚项来限制参数膨胀。对于树模型，可以通过限制树的深度和叶

子节点样本数来提前剪枝。如果是深度学习，常用Dropout随机丢弃一些神经元，

或者使用EarlyStopping，在验证集指标刚变差时就及时停止训练。

Q13：常见的分类模型有哪些？请简述逻辑回归（LogisticRegression）的原

理。

答题分析：

考察频率：★★★★★

考察点：考察基础算法原理

答题思路：列出主流分类器（LR、树模型、SVM等）。详细解释逻辑回归：通过

Sigmoid函数将线性回归的输出映射到(0,1)区间转化为概率，从而解决分类问题。

避坑点：忽略LR本质上是广义线性模型这一核心特征，说不清楚Sigmoid函数在里面扮演

的“非线性映射”的关键角色。

参考回答：

日常分析和挖掘里常见的分类模型有很多，比如逻辑回归、决策树、随机森林、支

持向量机以及XGBoost等。其中最经典的基线模型非逻辑回归莫属。

虽然它的名字里带有“回归”两个字，但它干的其实是分类的活，最常用来解决二分

类问题。它的底层逻辑是从最基础的多元线性回归演变过来的。我们知道线性回归

算出来的预测值是在负无穷到正无穷之间波动的，这没法直接判断分类。

为了解决这个问题，逻辑回归引入了一个关键的数学工具，也就是Sigmoid激活函

数。

它的原理就是把线性回归计算出的连续数值，像漏斗一样平滑地映射压缩到0和1的

区间里。这样一来，输出的结果就变成了一个概率值。我们只要设定一个阈值，比

如大于0.5就判定为正类，小于0.5判定为负类，非常直观。加上它的解释性极强，

业务上做归因特别方便。

Q14：决策树的分裂依据有哪些？（如信息增益、基尼系数等）

答题分析：

考察频率：★★★★

考察点：考察树模型基础

答题思路：对应三大经典决策树算法（ID3、C4.5、CART），分别讲出信息增益、信息

增益率、基尼系数的含义及优缺点。

避坑点：只知名词不懂含义。未说明信息增益偏向于选择取值较多的特征（如ID类特征）

这一致命缺点。

参考回答：

决策树在每一次向下分裂生长的时候，都在寻找那个能把数据分得最“纯净”的特

征。不同版本的决策树算法，衡量这种纯净度提升的依据是不一样的，主要有三

种。

最早期的是ID3算法，它用的是“信息增益”。简单说就是分裂前后系统信息熵的减少

量，谁减少得多就选谁。但它有个痛点，就是极其偏爱那种取值非常多、分支特别

细的特征，这很容易导致树长得过深。

为了修正这个问题，后来升级出了C4.5算法，它改用了“信息增益率”。在原有的基

础上引入了一个关于特征分支数量的惩罚项，算是平衡了特征取值多寡带来的偏

误。

我们现在工业界最常用的CART树，它采用的是“基尼系数”。基尼系数衡量的是从数

据集里随机挑两个样本，类别不一样的概率。它的好处在于计算非常快，不需要像

算熵那样去算对数，大大提升了模型训练效率，这也是随机森林的底层裂变逻辑。

Q15：K-Means聚类的K值如何选择？该算法对异常值敏感吗？

答题分析：

考察频率：★★★★

考察点：考察聚类算法理解

答题思路：讲出主流定K值的方法（肘部法则、轮廓系数，结合业务经验）。明确指出K-

Means对异常值极度敏感并解释原因（使用均值更新中心点）。

避坑点：纯依赖统计指标定K值，不考虑业务上是否具备可解释性和可落地性（比如算法

聚出13类，但业务根本没法针对13类做差异化运营）。

参考回答：

在使用K-Means做无监督用户分群时，K值的选择不能完全盲目。从技术角度看，

我通常会先用“手肘法”画出簇内误差平方和的曲线，找那个坡度明显放缓的拐点；

或者结合轮廓系数去跑，挑选类内紧凑、类间分散得分最高的那个K值。

不过在真实业务里，K值的拍定往往还要叠加运营部门的诉求。比如算法算出来分8

类最好，但运营资源有限，最多只能承接3到4类用户的差异化打法，这时候就需要

向业务妥协，适当降低K值。

至于异常值，K-Means算法对它是非常非常敏感的。

因为算法在每一轮迭代更新质心点的时候，用的是所有样本数据的算术平均值。只

要有一个偏离极其严重的极端异常点参与计算，整个质心就会被大幅度地往那个异

常方向硬拉过去，导致聚类结果严重变形。所以在进模型前，做好异常值的清洗拦

截是决定成败的前提。

Q16：评价分类模型好坏的指标有哪些？（如准确率、精确率、召回率、F1）

答题分析：

考察频率：★★★★★

考察点：考察模型评估指标

答题思路：用混淆矩阵引入，白话解释准确率、精确率（查准）、召回率（查全）和F1

的侧重点，结合医疗或风控等业务场景说明各个指标的取舍。

避坑点：分不清精确率（Precision）和准确率（Accuracy）的区别，或者在样本不平衡

场景下依然拿准确率说事。

参考回答：

评价分类模型不能只看一个孤立数字，要结合混淆矩阵里的具体指标来全面判断。

最基础的是准确率，也就是预测对的样本占总样本的比例。但在我们日常做留存预

测或风控时，正负样本通常极度不平衡，这时候准确率就失去了参考价值。

因此我们会更看重精确率和召回率。精确率讲究“查得准”，意思是模型预测出来的

正类里，有多少是真的正类。

召回率讲究“查得全”，意思是总体里所有真实的正类，模型成功找出来了多少。这

两个指标在业务上往往是打架的，很难同时兼顾。

比如做诈骗识别，我们宁可错杀也不愿放过，这时候就会对召回率有极高的要求；

但如果是推送广告短信，为了不打扰正常用户，我们就会优先卡紧精确率。如果想

综合权衡两者的表现，我们就会去参考F1-Score，它是两者的调和平均数，能反映

模型的整体综合实力。

Q17：ROC曲线和PR曲线有什么区别？数据不平衡时更倾向于看哪个？

答题分析：

考察频率：★★★★

考察点：考察高阶模型评估

答题思路：解释两条曲线的横纵坐标，强调ROC对正负样本比例变化不敏感的“稳定性”，

并指出在极端数据不平衡且关注正例表现时，PR曲线更真实严苛。

避坑点：死记硬背却张冠李戴。没有讲透为什么正负样本失衡时ROC会给出“盲目乐观”的

虚高表现。

参考回答：

ROC曲线和PR曲线都是通过调整分类阈值画出来的模型性能评估图，但它们的侧

重点有所不同。ROC曲线的横轴是假阳率，纵轴是真阳率，它的最大特点是非

常“稳”。也就是当测试集里的正负样本比例发生剧烈变化时，ROC曲线的形状基本

不会受影响。

PR曲线的横轴是召回率，纵轴是精确率。这决定了它把目光极其死死地盯在正样本

的表现上，对正负类失衡的情况非常敏感。

在真实的业务场景里，比如识别极其罕见的设备欺诈，正样本可能只有万分之一。

这时候如果看ROC曲线和计算出的AUC值，通常会非常高，给人一种模型表现极好

的虚假繁荣。

因为大量预测对的负样本稀释了指标。这种情况下，我们一定会更倾向于去看PR曲

线。只要模型在少数正类上出现了误判，PR曲线就会毫不留情地暴跌，它能更真

实、严苛地反映模型在极端不平衡环境下的实战能力。

Q18：线性回归的前提假设有哪些？如果违背了这些假设会怎样？

答题分析：

考察频率：★★★★

考察点：考察回归模型假设

答题思路：列出经典四大假设（线性、独立、正态、同方差）。说明违背假设的后果（如

预测偏差大、假设检验失效）以及简单的应对方案。

避坑点：只回答了名词，没有解释背后的业务危害，比如异方差会导致置信区间估算错

误。

参考回答：

我们在用线性回归去做归因或预测时，底层是有严格假设前提的，最核心的主要有

四个。

首先是线性关系，自变量和因变量之间确实存在线性趋势；其次是独立性，样本观

测值之间不能互相影响；第三个是误差项要服从正态分布；最后一个是同方差性，

也就是不管自变量怎么变，误差的波动范围应该大致是一致的。

如果用数据跑模型前没做校验，违背了这些假设，模型结果就会骗人。比如违背了

线性假设硬做拟合，那预测出来的值肯定偏离业务实际。

如果出现了异方差现象，比如随着用户年龄增大，消费金额的残差波动越来越剧

烈，这时候模型算出来的P值和置信区间就完全失效了。导致我们可能把本来没用

的特征误判为重要特征。遇到这类问题，我通常会通过对因变量取对数，或者加入

多项式特征来尽早做干预修正。

Q19：简述PCA（主成分分析）的降维原理及适用场景。

答题分析：

考察频率：★★★

考察点：考察降维算法知识

答题思路：用投影的视角解释方差最大化思想（保留核心信息）。适用场景包括解决多重

共线性、压缩高维数据加速训练等。

避坑点：数学公式推导过多，忽略了PCA一个最大的业务软肋——降维后的新特征几乎

完全丧失了原有的业务可解释性。

参考回答：

PCA主成分分析是一种非常经典的无监督降维技术。它的底层原理，用通俗的话

说，就是在一堆复杂的维度里寻找新的坐标轴，然后把原始数据投影过去。它寻找

新坐标轴的标准是让数据投影后的方差尽可能大。

因为方差越大，说明数据散得越开，保留下来的原始信息就越多。通过提取排在前

面的几个主成分，我们就能用极少的维度替代原来几十上百个指标。

在业务场景里，当我们拿到一份包含几百个用户行为指标的宽表，且这些指标之间

存在严重的多重共线性时，直接跑模型会非常吃力。这时候做个PCA压缩一下，既

能降低噪音，又能大幅缩短模型训练时间。

不过它也有一个很明显的业务硬伤，就是经过线性组合降维后产生的新特征，通常

很难给出直观的业务解释。所以如果业务部门极其看重归因分析，我就会谨慎使用

它。

Q20：遇到缺失值和异常值，你在统计学上通常有哪些处理策略？

答题分析：

考察频率：★★★★★

考察点：考察数据清洗理论

答题思路：针对缺失值分情况讨论（直接删、均值/中位数填充、模型预测填充）。针对

异常值阐明识别机制（箱线图、3σ）和处理手段（盖帽法、分箱法）。

避坑点：不分青红皂白上来就说“直接删掉”或“全部用均值填”。数据清洗极其考验对业务

逻辑的判断力，缺失本身有时也是一种信息。

参考回答：

对于清洗缺失值和异常值，绝不能有一刀切的机械操作，必须结合具体的业务含义

来定。

遇到缺失值，如果缺失比例非常小，而且字段对核心业务影响不大，最干脆的做法

是直接丢弃。如果是连续型数值，分布比较均匀我就用均值填，如果是长尾偏态我

就用中位数去填，避免被极值拉偏。如果这个字段很重要，我也会尝试用随机森林

之类的算法做预测填充；有时候缺失本身就是一种用户行为，我会直接给它独立编

个码。

对于异常值，我通常会先用箱线图的四分位距或者3Sigma法则把它揪出来。

如果确认是系统采点bug导致的脏数据，就剔除。如果是真实存在的极端土豪用户

拉高了指标，那显然不能删。我会采用盖帽法，把极值强制压到某个合理的分位

点；或者干脆放弃用连续值，直接做分箱离散化处理，把指标变成“高、中、低”的

分类，这样模型就能很好地免疫异常值的冲击。

二、SQL与数据库基础（20道）

SQL是数据分析师吃饭的家伙。本章节侧重考察同学们在真实业务环境下提取和处

理数据的基本功，重点检验大家应对复杂表结构时的逻辑思维与代码落地能力。

Q21：SQL中WHERE和HAVING的区别是什么？执行顺序是怎样的？

答题分析：

考察频率：★★★★★

考察点：考察SQL基础语法

答题思路：核心区别在于作用对象和执行时机（WHERE过滤原始行数据，HAVING过滤

分组后的聚合数据）。指出执行顺序的先后关系。

避坑点：混淆两者使用场景，不知道HAVING后面通常跟聚合函数（SUM/COUNT等），

或者不知道WHERE阶段无法使用别名。

参考回答：

WHERE和HAVING在SQL里都是用来做条件过滤的，但它们生效的阶段和作用对

象截然不同。

WHERE是第一道关卡，它是在数据库进行分组聚合并提取数据之前就开始生效

的。它是对底层的原始明细数据按行进行逐一筛选。正因为这时候还没有做任何统

计，所以WHERE后面绝对不能跟着诸如SUM或者COUNT这样的聚合函数。

而HAVING是第二道关卡，它专门为GROUPBY服务。当原始数据按照维度分组，

并且完成了聚合计算之后，HAVING才登场。它主要是利用前面算出来的聚合结果

再做一轮筛选过滤。

从执行顺序上看，SQL引擎一定是先执行WHERE把底表过滤变小，接着执行

GROUPBY进行分组聚合，最后才轮到HAVING去过滤分组后的宏观结果。在写取

数逻辑时搞清这个顺序，不仅不容易报错，还能提升查询效率。

Q22：请详细说明SQL查询语句（SELECT）中各关键字的执行顺序。

答题分析：

考察频率：★★★★★

考察点：考察SQL底层逻辑

答题思路：完整梳理SQL标准的底层执行管线：FROM->JOIN->WHERE->GROUP

BY->HAVING->SELECT->ORDERBY->LIMIT。

避坑点：顺序背错。特别是把SELECT的执行时机放得太靠前，导致无法解释为什么在

WHERE里不能使用SELECT定义的字段别名。

参考回答：

搞懂SQL查询关键字的底层执行顺序，是我们做性能调优和排错的基础。一个完整

的查询请求发过去，数据库引擎其实是按照一套死板的流水线来干活的。

整个流程的起点是FROM和各种JOIN操作，引擎会先把几张大表拼凑出想要的一张

巨大虚拟底表。接着进入WHERE阶段，按照条件把那些不需要的行直接砍掉。

然后才是用GROUPBY把剩下的数据按照维度打成一个个分组，紧跟着用HAVING

把不符合要求的组整体踢出去。直到这一步做完，才终于轮到SELECT指令出场，

去挑选并计算我们要展示的具体列。

最后一步是修饰输出环节，先用ORDERBY给拿到的结果排个序，如果加了

LIMIT，就在排好序的结果里截取前几行返回。明白了这个逻辑顺序，我们平时写代

码就自然知道为什么不能在WHERE里提前用SELECT刚才定义的别名了。

Q23：各种JOIN操作（INNER,LEFT,RIGHT,FULL）有什么区别？

答题分析：

考察频率：★★★★★

考察点：考察表连接逻辑

答题思路：以集合的文氏图视角，简明扼要说明内连接、左连接、右连接和全外连接的保

留逻辑及空值（NULL）填充表现。

避坑点：忽略了在业务里最常用的其实是LEFTJOIN，未提及没匹配上导致产生NULL值

的处理意识。

参考回答：

日常分析取数做多表关联时，JOIN的选择直接决定了我们要保留怎样的数据底盘。

最严格的是INNERJOIN内连接，它只保留两张表里键值完全匹配得上的交集数

据，如果任何一边缺了对应记录，这行数据就彻底抛弃。

但在真实的业务报表里，我们用得最多的是LEFTJOIN左连接。它是以左边那张表

为主干，左表的数据一条不漏全保留。如果右表里有匹配的信息就贴上来，如果没

有匹配上，就强行补上NULL值。这就保证了我们主视角的业务数据底座不丢失。

RIGHTJOIN逻辑刚好反过来，是以右表为基准。至于FULLJOIN全外连接，则是

把两张表的底盘全盘兜下，只要有数据就保留，匹配不上的全用NULL填补。不过

在很多大数据引擎里，全连接非常消耗性能，我们往往会拆分成多次左连接或者用

UNION来替代实现。

Q24：什么是窗口函数？Row_Number()、Rank()和Dense_Rank()的区别是

什么？

答题分析：

考察频率：★★★★★

考察点：考察高阶窗口函数

答题思路：定义窗口函数（不折叠行数的聚合分析）。通过相同的打分场景，清晰区分三

个最核心排序函数的序列规则（123,113,112）。

避坑点：描述不清并列排名时的递增逻辑，这也是机试手撕SQL环节极容易导致排序序号

错乱的丢分点。

参考回答：

窗口函数是我们做复杂数据分析的杀手锏。普通的GROUPBY聚合会把多行明细数

据给折叠合并成一行，但窗口函数能在做聚合、排序计算的同时，依然原封不动地

保留原始明细行。

在做各类TopN排行榜或者计算连续行为时，我们最常用到三个排序窗口函数，它

们对待“成绩并列”的态度完全不同。

Row_Number()是最冷酷无情的排队方式。哪怕两个用户的分数一模一样，它也会

强制按顺序给出1、2、3、4的编号，绝对不会出现重复名次。

Rank()则允许名次并列，如果两个第一名，它会标成1、1，但它会占用掉后面的名

次，下一个分数直接就变成了第3名，也就是出现了名次跳跃。Dense_Rank()叫稠

密排名，遇到并列第一标为1、1后，下一个分数紧接着算作第2名，名次完全连续

不断层。我会根据业务端对榜单的实际诉求来灵活切换。

Q25：如何用SQL实现用户留存率的计算？（例如次日留存、7日留存）

答题分析：

考察频率：★★★★★

考察点：考察核心业务SQL实现

答题思路：梳理留存计算的两步逻辑：找新客/活跃基准表->关联未来日期表。强调通过

自连接（LEFTJOIN）并计算日期差（DATEDIFF）来完成分子分母的统计。

避坑点：死记硬背复杂代码，讲不清楚“左表找大盘基数，右表找次日回访，除一下就是

留存”这套最直白的业务取数逻辑。

参考回答：

计算留存率是日常分析里高频的祖传SQL，核心思路就是去对比用户在某一天活跃

后，未来特定几天是否还回来。

我通常会分两步走。第一步是先把基准表构造出来，也就是我们要圈定这批观察样

本。比如要看次日留存，我会先拿活跃日志表按用户和日期去重，这就得到了左

表，代表当天活跃的用户基数，用来当分母。

第二步是做自连接。我拿这个左表去LEFTJOIN它自己，关联条件是用户ID必须相

同，而且右表的日期刚好比左表的日期大一天。在主流数据库里可以用DATEDIFF

函数限定相差等于1。

这时候做统计就很清晰了。每天的基准人数就是对左表的用户ID去重计数；而次日

还回来的活跃人数，就是对成功关联上右表的用户ID计数，充当分子。两者一除，

次日留存率就出来了。如果要算7日留存，只需要把日期差换成7就行，逻辑高度复

用。

Q26：如何用SQL找出连续登录N天以上的活跃用户？

答题分析：

考察频率：★★★★★

考察点：考察复杂逻辑SQL能力

答题思路：这是非常经典的连续行为判断题。核心思路是利用排序窗口函数打序号，然后

将原始日期减去序号构造出一个基准差值，连续的时间相减会得到相同的基准日期，最后

基于这个差值分组即可。

避坑点：忽略了前期去重工作。同一个用户在同一天可能有多次登录日志，如果不提前进

行按天去重，窗口排序号就会乱，导致连续性判断彻底失效。

参考回答：

计算用户连续登录是校招机试里的常客。这个需求看似复杂，但只要转变一下思

路，利用窗口函数就能很巧妙地解开这道题。

第一步肯定是做数据清洗。我们需要对原始的用户登录日志进行去重，保证一个用

户在同一天哪怕登录了多次，也只保留一条记录。这是为了防止后续排序时产生重

复名次干扰我们的判断基准。

接着是最核心的一步。我们会用到Row_Number函数，按照用户ID进行分组，并按

登录日期从小到大排个序，给每一次登录打上一个连续递增的序号。

这时候有趣的数学规律就出现了。如果用户的登录是连续的，那么登录日期也是连

续递增的，它减去刚才生成的那个连续递增的序号，得到的一个“基准日期”应该完

全一样。

所以我们只需要用日期减去排序号得到差值字段，然后按用户ID和这个差值字段做

一次聚合。在此基础上加上Having过滤条件，看看这个组里的记录数是不是大于等

于N，就能把满足连续登录天数的用户精准挑出来了。

Q27：如何用SQL求解单日累计最高在线人数？

答题分析：

考察频率：★★★★

考察点：考察特定场景SQL应用

答题思路：典型的“流式数据状态累加”问题。需要将登录和登出动作拆分为正负数值（+1

和-1），合并成流水表，再顺着时间线进行累加求和，最后找寻最大值。

避坑点：对“同一秒既有人进又有人出”这种并发边界情况欠考虑，导致算出来的瞬时峰值

偏高或偏低，体现不出思维的严密性。

参考回答：

求解单日最高同时在线人数是非常经典的业务场景题。面对这种随时间动态变化的

状态，我们不能直接硬算，而是需要用到打标签的思路。

我们可以把用户的每一次会话拆解成两个独立动作：登入和登出。操作的第一步，

是把用户的登入时间提取出来，并在旁边增加一列记为正一，代表此时在线人数增

加了一个；同时把登出时间也提出来，记为负一，代表在线人数减少。

随后我们要把这两份数据做一次Union合并，相当于把全天所有的进出动作合并成

一张动作流水表。为了严谨起见，如果碰巧有用户在同一秒登入和登出，我们要保

证先算登出再算登入，这样符合业务上对峰值的保守估计。

完成底表构造后，重头戏就是用SUM聚合函数结合窗口函数。我们按照时间发生先

后进行全局排序，把那个加减一的字段进行累计求和。每一行算出来的累计值，其

实就是当下的实时在线总人数。

通过这种流水账累加的方式，直接在最外面套一层MAX函数，就能轻松拎出这一天

里那个在线人数的最高峰值了。

Q28：COUNT(*)、COUNT(1)和COUNT(列名)的区别及性能差异是什么？

答题分析：

考察频率：★★★★

考察点：考察聚合函数理解

答题思路：重点从“是否包含空值”和“数据库引擎底层优化”两个维度作答。前两者算行数

不过滤NULL，后者针对具体列会过滤NULL。

避坑点：还在背诵十年前的陈旧面经，认为COUNT(1)一定比COUNT(*)快，忽略了现代

数据库引擎早已把它们优化为相同执行计划的客观事实。

参考回答：

日常取数时我们天天都在写COUNT函数，但它们在统计逻辑和底层执行上还是有一

些细微区别的，稍不注意就会算出偏差。

最本质的差异在于对空值的处理态度。COUNT星号和COUNT数字一，它们在统计

的时候是连带着空值一起算的，也就是只要这一行有数据存在，不管里面的字段是

不是NULL，都会被计入大盘总数。

而COUNT具体列名就严格很多。它会去老老实实检查这一列的值，只要碰到NULL

值，就会直接跳过不统计，出来的数字往往会比前两个要小。这点在统计活跃用户

或者有消费记录的用户时需要特别注意，用错就容易把业务指标算高。

关于性能上的差异，在现在的关系型数据库比如MySQL的InnoDB引擎下，COUNT

星号和COUNT数字一的底层执行计划已经被优化得几乎一样了，查询效率并没有明

显差别。

如果是COUNT列名，数据库为了判断是不是空值，还得专门去读取这列的具体数

据。如果这列没有建索引，甚至会引发全表扫描，速度就会慢很多。

Q29：UNION和UNIONALL的区别是什么？哪一个性能更好？

答题分析：

考察频率：★★★★★

考察点：考察结果集合并语法

答题思路：两者都是表拼接。指出核心分水岭：是否去重。阐明由于去重动作在底层引发

了耗时的内存排序操作，使得前者的性能大打折扣。

避坑点：只讲两者表现形态不同，没能结合CPU和内存的消耗痛点说透性能差异的根

源，或者平时业务里永远只知道图省事写UNION。

参考回答：

在做跨表数据纵向拼接的时候，这两个关键字可以说是我们的左膀右臂，但选错的

话对大数据环境下的查询性能影响非常大。

它们最大的区别在于要不要做去重这道工序。UNIONALL的作用非常简单粗暴，它

就是把两个查询结果上下贴在一起，不管里面有没有重复的明细行，统统保留下

来。这就像是把两个Excel表的数据不加修饰地硬拼成一张大宽表。

而UNION不仅会做拼接，还会在底层默默地做一次去重操作。它会把两份结果集里

完全一模一样的数据剔除掉，只保留唯一的那一份。

这就导致了它们在执行性能上存在明显差距。UNION因为需要去重，数据库在底层

往往需要把整个庞大的结果集放进内存里做一次全局排序比对，极其消耗资源，数

据量稍大就容易把查询拖慢。

所以在业务取数时，如果能通过前置条件确保两张表的数据本来就没有交集，或者

业务逻辑本身就允许存在重复明细，我一定会优先使用UNIONALL来减轻计算引擎

的负担。

Q30：什么是数据倾斜？在使用SQL处理大数据时如何解决数据倾斜问题？

答题分析：

考察频率：★★★★

考察点：考察大数据处理概念

答题思路：解释大分配不均导致少数计算节点卡死的问题。结合常见诱因（空值聚集、头

部热点ID），分别给出打散处理的对应解决方案。

避坑点：答题过于理论化，没有举出“头部主播流量聚集”、“脏数据未清洗”等生动的业务

场景来验证自己对分布式计算痛点的理解。

参考回答：

数据倾斜是我们在处理大数据量时经常遇到的拦路虎，特别是在跑Hive任务的时

候。简单来说，就是我们在做关联或者聚合时，绝大部分数据都涌向了少数几个节

点，导致大部队早就干完活了，只能干等着那一两个节点慢吞吞地跑。

造成这种现象最常见的原因有两个。一个是用来连接或者分组的字段里，存在大量

未清洗的空值；另一个是某个具体的业务ID是个大热点，比如几百万人都去点击了

同一个头部商品。

应对的方法我通常会分场景来看。如果是空值造成的倾斜，最省事的办法就是在进

入分布式计算前，先把不影响业务逻辑的空值过滤掉，或者给空值赋予一些随机的

乱码字符串，把它们强行打散到不同的节点去。

如果是热点数据带来的倾斜，我会采用两阶段聚合的思路。先给这些热点ID拼接上

一个随机数做前缀，进行第一阶段的局部聚合，把庞大的数据量压下来。然后再把

那个随机前缀去掉，进行全局聚合，这样就能把原本压在一个节点上的计算压力完

美摊薄。

Q31：EXISTS和IN有什么区别？在什么情况下使用EXISTS效率更高？

答题分析：

考察频率：★★★★

考察点：考察子查询性能优化

答题思路：解析“内驱动外”和“外驱动内”的执行原理。总结出“小表驱动大表”的金科玉律，

依据内外表的相对大小推导出各自的适用场景。

避坑点：死记硬背“EXISTS永远比IN快”这种毫无依据的绝对言论。在实际业务里，外表大

而内表极小时，用EXISTS反而慢得离谱。

参考回答：

写嵌套子查询的时候，大家往往纠结用EXISTS还是IN，这背后其实是一个“谁驱动

谁”的底层查询优化问题。

IN的工作模式是由内向外的。数据库会优先把括号里那个子查询彻底跑完，生成一

个结果集放到内存里，然后再去遍历外面的主表，拿着外表的数据去这个结果集里

挨个对比。这也就意味着，如果子查询的结果集非常小，用IN的体验就会非常好。

相反，EXISTS的逻辑是由外向内的。它会去老老实实地遍历外面主表的每一行记

录，然后把这行记录带入到子查询里面去验证。只要子查询能查出哪怕一条匹配的

数据，EXISTS就会立刻返回真，阻断多余的扫描。

所以我们在业务优化时要看具体的表大小分布。如果是外表非常巨大、而子查询里

的表很小，用IN会更聪明。但如果外表是一张只有几万行的小表，而里面用来过滤

的是一张几千万行的明细大表，这时候用EXISTS的效率就明显高得多。

Q32：SQL中如何进行行转列、列转行操作？

答题分析：

考察频率：★★★★

考察点：考察数据格式转换

答题思路：分别针对传统关系型数据库（CASEWHEN+聚合/UNIONALL）和大数据

环境（内置炸裂函数），给出具体的转化方法论。

避坑点：解释行转列时，光说了CASEWHEN却忘了外面必须要套上一层聚合函数（如

SUM/MAX），这样根本无法完成“把多行压成一行”的核心动作。

参考回答：

我们在做数据分析报表时，经常需要配合业务方看数据的视角把展示方向做个翻

转，这就绕不开行转列和列转行的操作。

行转列通常是为了把细长条的流水数据变宽，方便对比。比如把按月份存储的销售

流水，转换成十二个月份并排显示的横表。这个场景我最常用的是利用GROUPBY

配合CASEWHEN语句来写。按商品维度分组后，里面写多个CASE判断分发指

标，外面务必套一个MAX或者SUM函数一聚合，行数据就乖乖躺平成列了。

列转行则是相反的过程，主要是为了把横向的多列维度展开成多行，方便做下钻分

析。在传统关系型数据库里，最朴素的做法就是把不同列单独查询出来，然后用

UNIONALL像搭积木一样上下堆叠起来。

如果是放在大数据环境比如Hive里，操作就优雅很多了。我们会直接用LATERAL

VIEW配合EXPLODE函数，这种内置的表生成利器能一次性把宽表里的数组炸开

成多行，代码写起来十分简洁。

Q33：解释一下数据库中主键、外键和唯一索引的区别。

答题分析：

考察频率：★★★★★

考察点：考察数据库约束概念

答题思路：用业务类比指出三者的职责定位（主键：身份唯一标识，不可空；外键：跨表

关联约束；唯一索引：单列或多列防重复，可为空）。

避坑点：分不清主键和唯一索引的核心区别，不知道一张表只能拥有一个主键，但却可以

根据不同业务需求建立多个唯一索引。

参考回答：

在数据库设计和约束机制里，主键、外键和唯一索引各自扮演着不同的底层安保角

色。

主键就像是每行数据的身份证号，它是用来唯一标识一条记录的核心字段。既然是

身份证，它不仅要求里面的值绝对不能有重复，而且严禁为空。一张表里只能有一

个主键，它是维持单表数据结构完整的基石。

外键的作用是用来维系不同业务表之间的纽带关系。比如订单明细表里的用户ID，

通常是用户画像表里的主键。外键的作用就是确保大家不能凭空捏造数据，你不能

在订单表里塞入一个用户表里根本不存在的神秘用户，它在保护跨表数据的一致

性。

唯一索引的侧重点主要是为了加速查询和防止特定字段出现重复。它和主键很像，

也要求数值不能重复，比如用户的注册手机号就常建唯一索引。但它的态度稍微宽

容一些，它是允许存在空值的，而且一张表里可以建立好几个不同列的唯一索引。

Q34：数据库索引的底层数据结构通常是什么？为什么不用哈希表？

答题分析：

考察频率：★★★★

考察点：考察索引底层原理

答题思路：点明主流是B+树。解释哈希表虽点查速度极快，但在实际业务中最常遇到

的“范围区间查询”面前毫无招架之力，而B+树的叶子节点链表天然适合扫库。

避坑点：没能在解释纯技术底层结构时，及时地把话题往“分析师高频使用的区间条件

（大于小于）查询”这类实际应用场景上靠拢。

参考回答：

主流关系型数据库的底层索引结构，基本都是不约而同地选择了B+树，而不是理论

上单次查询极快的哈希表，这是由真实的业务查询场景决定的。

哈希表查找单条记录确实快，时间复杂度几乎是一，通过键值一算就能直接定位到

数据。但它有一个致命的业务缺陷，哈希计算后的数据分布是完全无序的散列状

态。我们在做数据提取时，极少会只查单独的一个特定ID。

更多的时候，我们是在做范围查询。比如我们要捞取上个月所有的活跃用户，或者

是挑选出积分大于五百的高价值客户。这时候哈希表就彻底傻眼了，因为毫无规律

可循，它只能去做灾难性的全表扫描。

而B+树这种结构是天然支持范围查询的。它的所有实际数据都老老实实按顺序排在

最底层的叶子节点上，而且叶子节点之间还有双向链表相连。一旦找到了范围的起

点，顺着链表一路扫过去就行，硬盘读取也是连贯的，非常贴合我们的取数诉求。

Q35：什么是事务？事务的ACID特性具体指什么？

答题分析：

考察频率：★★★★★

考察点：考察数据库事务基础

答题思路：用“打包执行动作”直白解释事务概念。依次结合白话解释原子性（同生共

死）、一致性（状态守恒）、隔离性（并发不干扰）和持久性（落盘稳固）。

避坑点：名词解释过于干瘪。建议直接套用“银行转账”或“电商下单库存扣减”等经典场

景，能迅速展现把死知识盘活的能力。

参考回答：

事务其实就像是一组被打包好的连贯动作。在数据库里，我们要么把这些动作全部

顺利执行完，要么就一个都不做，绝不留半途而废的烂摊子。比如电商平台下单，

扣减库存和生成订单记录必须作为一个事务同时成功或失败。

它背后依靠的就是大名鼎鼎的四个特性。第一点是原子性，就是刚才说的不可分

割，所有操作同生共死，遇到中间某一步报错就整体倒退回原始状态。

第二点是一致性。比如转账前后，两个人的账户总余额加起来得对得上，数据库不

能因为操作中断凭空把钱算没了。

第三点是隔离性，业务高并发大促的时候，有好几拨流量同时在修改同一批数据。

隔离性就是保证这些在暗中同时进行的事务互相看不到对方的中间状态，避免出现

读取了还没落库的脏数据。

另外还有一个重点是持久性。只要系统提示你这个事务提交成功了，哪怕下一秒机

房断电宕机，这条数据也已经牢牢刻在了硬盘上。

Q36：慢SQL查询通常有哪些优化思路？

答题分析：

考察频率：★★★★★

考察点：考察SQL优化能力

答题思路：一套组合拳打下来：EXPLAIN查执行计划看索引->避免在过滤列上做计算->

只选必要列->小表驱动大表->大数据引擎加盐防倾斜。

避坑点：只会说“建索引”，但不知道在已有索引的情况下，哪些糟糕的代码书写习惯（如

在WHERE等号左边做数学运算或函数包裹）会导致索引直接失效。

参考回答：

遇到跑很久都出不来结果的慢报表SQL，我通常会有一套顺藤摸瓜的系统排查思

路。

遇到这种情况，我一定会先在查询语句前面加个E