sql面试需掌握业务场景深度：漏斗分析重行为时序与去重，留存率重日期处理与新用户定义，订单分析重状态时效与时区，指标对齐重样本验证与NULL处理。
SQL面试中，光会写基础查询远远不够。真实业务场景下的SQL题，往往涉及多表关联、时间窗口分析、去重逻辑、指标计算偏差处理等细节，稍不注意就会掉进坑里。
一、用户行为漏斗分析（常见于电商/内容平台）
题目常给一张用户行为日志表（user_id, event_type, page, timestamp），要求计算从“首页曝光”→“商品点击”→“加入购物车”→“下单”的转化率。
关键点不是写JOIN，而是理解业务逻辑：
- 行为顺序不能错：必须是同一用户在合理时间窗口内（比如24小时内）的有序行为，不能简单按event_type分组count；
- 去重要谨慎：一个用户一天多次“下单”，只算1次转化，但“首页曝光”可能有几十次，需用MIN(timestamp)或ROW_NUMBER()锚定首次路径；
- 漏斗断层要归因：如果“加入购物车”人数远低于“商品点击”，可能是加购按钮埋点漏报，SQL里得先验证event_type值是否完整（select DISTINCT event_type）。
二、留存率计算（DAU类指标高频考点）
给定login_log表（user_id, login_date），求次日留存率、7日留存率。
很多候选人直接用LAG或自连接，但线上数据常有陷阱：
- 日期字段类型要确认：login_date是DATE还是DATETIME？如果是后者，需先CAST或DATE()截取；
- “新用户”定义必须明确：是首次登录当天为基准日，还是注册日？面试官没说清时，要主动问——真实业务中这个口径直接影响结果；
- 避免笛卡尔积式自连接：用LEFT JOIN + 条件 ON t1.user_id = t2.user_id AND DATEDIFF(t2.login_date, t1.login_date) = 1 更稳，再配合COUNT(DISTINCT t1.user_id)做分母。
三、订单状态变更分析（金融/交易系统典型题）
订单表orders（order_id, status, update_time），status含’created’/’paid’/’shipped’/’cancelled’，要求查出所有“已支付但未发货且超2小时”的订单。
这题考的是对状态时效性的敏感度：
- 不能只看最新一条记录：一个订单可能反复改状态（如paid→cancelled→paid），要用窗口函数取每个order_id按update_time排序的最新status；
- 时间比较要带时区意识：update_time是UTC还是本地时间？面试中若没提，默认按题干时区处理，但可备注“生产环境需统一时区”；
- NULL值要兜底：shipped时间可能为空，WHERE shipped_time IS NULL比!= ‘shipped’更安全，因为status字段可能存其他值（如’refunding’）。
四、指标口径对齐与调试思维
当SQL结果和BI报表数字对不上，怎么办？
- 先查样本：随机取5个user_id，人工核对原始日志中的行为链路；
- 拆解中间表：把漏斗每一步单独查出来（如只查“首页曝光且有后续点击”的用户数），定位哪一环掉量异常；
- 检查NULL和空字符串：GROUP BY字段是否含NULL？COUNT(*)和COUNT(col)差异是否被忽略？这些在真实数据中极常见。
业务SQL不是炫技，核心是用数据还原真实场景。写完别急着交，多问自己一句：“这个结果，运营同学拿到能直接用吗？”