跳到主要内容

面试SQL文章质量审计规则

用途：新生成文章时逐条核对，确保质量与已修正文章一致。 参考标准：阿里 ali / B站 bilibili 已修正文章。

一、Frontmatter 规范​

---
title: "SQL 文章主标题：核心技术点（公司简称面试题）"
sidebar_label: "序号. 短标题"
description: "公司名大数据面试SQL-文章关键词"
keywords: ["SQL","公司SQL面试题","考点1","考点2","业务关键词"]
difficulty: "easy | medium | hard"
position: 序号
---

检查项：

  • title 格式：SQL 业务场景：核心技术点（公司名面试题）
  • sidebar_label 格式：序号. 中文短标题（如 01. UP主粉丝增长趋势）
  • description 包含公司名 + 业务关键词
  • keywords 至少包含 SQL、公司SQL面试题、2-3个核心技术点
  • difficulty 与题目难度一致
  • position 为两位数序号

二、章节结构（八段式，缺一不可）​

# SQL 主标题（一级标题，与 frontmatter title 一致）

## 一、题目背景
## 二、题目
## 三、思路分析
## 四、逐步推导
## 五、常见坑点
## 六、举一反三
## 七、知识点总结
## 八、建表语句和数据插入（折叠块）

检查项：

  • 一级标题与 frontmatter title 一致
  • 禁止出现两个"一、"章节
  • 禁止跳过"二、"直接从"一、"到"三、"
  • 禁止出现 ⚠️ 待修正 标记
  • 章节编号为中文数字：一、二、三、四、五、六、七、八

三、题目背景（一、）​

写作要求：

  1. 点名具体部门/岗位："这道题来自 B站内容生态部门的数据分析岗面试"
  2. 解释业务概念：这个业务为什么重要，对公司意味着什么
  3. 说明实际用途：谁会看这个数据，看了之后做什么决策
  4. 引用块（>）给出具体场景：周报/月报/复盘会的名称

反例（禁止）：

这道题来自B站的数据分析岗面试。B站是弹幕视频社区，数据分析师需要从海量业务数据中挖掘洞见。
> 内容消费相关需求在日常工作中频繁出现，这类型的SQL题是面试高频考点。

正例（参考）：

这道题来自B站内容生态部门的数据分析岗面试。B站有超百万UP主，内容创作者生态是B站的核心竞争力。
运营团队需要持续监控UP主的粉丝增长趋势，识别快速涨粉的优质创作者给予流量扶持...

> **业务场景**：每周运营周报需要输出"本周涨粉最快TOP10 UP主"和"涨粉速率趋势图"...

检查项：

  • 点名了具体部门/岗位
  • 解释了业务概念和重要性
  • 说明了数据用途和决策链路
  • 引用块给出了具体场景名称
  • 背景内容与当前题目业务场景一致（非通用模板）

四、SQL 代码规范​

4.1 关键字大小写​

强制要求：所有 SQL 关键字全部小写，无一例外。

类别示例
DMLselect, from, where, group by, order by, having, limit
DDLcreate table, insert into, values
JOINleft join, join, on
窗口函数row_number(), rank(), dense_rank(), lag(), lead()
聚合函数count(), sum(), avg(), max(), min()
条件函数case when ... then ... else ... end, coalesce(), nullif()
类型转换cast(... as decimal), cast(... as int)
日期函数datediff(), date_add(), substr()
其他distinct, as, in, not, is null, is not null, and, or, between

4.2 DDL 格式​

create table tX_表名 (
    字段1  类型  comment '中文注释',
    字段2  类型  comment '中文注释'
) comment '表中文描述';

insert into tX_表名 values
(值1,值2,值3),(值1,值2,值3);

检查项：

  • 字段名对齐（用空格补齐到相同宽度）
  • 每个字段有 comment
  • 表级有 comment
  • 类型与数据匹配（string, int, bigint, decimal(10,2)）
  • 一条 insert 不超过 3 行数据，多行换行对齐

4.3 逐步推导格式​

要求分2-3个步骤，每步包含：

  • 步骤标题：### 步骤N：一句话描述
  • SQL 代码块
  • 执行结果表格（可选但推荐）
  • 结果解读（> 引用块，1-2句话）

检查项：

  • medium 和 hard 难度至少 2 个步骤
  • easy 难度可以 1 个步骤，但建议拆分为 2 步
  • 每步有 SQL + 结果 + 解读
  • SQL 在 ```sql 代码块中

五、常见坑点（五、）​

写作要求：

  1. 每条坑点必须与当前题目直接相关——不能是通用坑点模板
  2. 每条坑点格式：坑点名称（粗体） + — + 具体说明
  3. 说明中包含：什么问题 + 为什么出现 + 怎么解决
  4. 使用行内代码块 ` 引用具体函数/语法

🚨 最严重错误：复制粘贴其他文章（不同业务场景）的坑点

正例（B站视频互动率题目）：

**坑1：除数为零导致运行报错**
播放量 `plays` 可能为0，直接做除法会触发"除以零"错误。必须用 `nullif(plays, 0)` 将0转为NULL。

**坑2：整数除法精度丢失**
`coins / plays` 在部分SQL引擎中两个整数相除会返回整数（截断为0）。解决方案是 `coins * 1.0 / plays`。

**坑3：互动指标之间的关联性被忽略**
单独看每个比率容易产生片面结论。面试中可以主动提出用散点图分析三者之间的相关性。

反例（出现了"骑手""配送""延迟订单"等无关内容）：

**坑1：分子分母的业务定义** — 明确分子是"延迟订单数"还是"延迟用户数"...
**坑2：时间差计算的单位** — unix_timestamp 返回秒，除以60才是分钟...

检查项：

  • 每条坑点与题目业务场景一致
  • 不包含其他业务领域的术语
  • 每条坑点有具体的技术细节（函数名/语法）
  • 每条坑点给出了解决方案
  • 至少 2 条，建议 3 条

六、举一反三（六、）​

写作要求：

  1. 每条必须是当前题目的变体——换个角度问同一个业务问题
  2. 每条格式：序号. **主题（粗体）**：具体描述
  3. 描述中包含具体的技术做法（用什么字段、什么函数、什么逻辑）

🚨 最严重错误：通用模板（"增加时间维度对比""增加分组维度""设置预警阈值"）

正例（B站粉丝增长题目）：

1. **周/月涨粉榜**：将 `date` 按周/月截断，先 `sum(daily_growth)` 聚合到周/月粒度，再做排名
2. **涨粉速率分级**：用 case when 将日增量分为四档，统计各类UP主占比
3. **异常掉粉检测**：设置阈值 `where daily_growth < -500`，筛选单日掉粉超过500的UP主

反例（禁止）：

1. 增加时间维度对比：按天/周/月分组，观察指标的趋势和季节性波动
2. 增加分组维度：按品类/地区/渠道拆解，发现差异化的业务洞察
3. 设置预警阈值：在WHERE中加阈值判断，自动筛选异常数据

检查项：

  • 每条与当前题目的业务场景一致
  • 每条包含具体技术做法（字段名/函数名/阈值）
  • 不出现通用的"增加维度对比""增加分组维度""设置预警阈值"模板文字
  • 至少 3 条

七、知识点总结（七、）​

写作要求：

  1. 只列出当前 SQL 中实际用到的考点——不能列出未使用的考点
  2. 表格格式：| 考点 | 说明 |
  3. 考点名称使用中文描述 + 关键函数名

🚨 常见错误：

  • 列出 sum() over 累积求和 但 SQL 中根本没用到窗口聚合
  • 列出 case when 条件聚合 但 SQL 中没用 case when
  • 知识点太少（只有1行），medium/hard 题目至少 3-4 个考点

正例（B站弹幕峰值）：

| 考点 | 说明 |
|------|------|
| floor 分桶 | 将连续时间值离散化为等宽窗口，常用于时间轴降维 |
| row_number + partition by | 每组内排序后取第一名，实现"每组Top 1" |
| count + group by | 按窗口分组统计弹幕数，配合窗口函数取峰值 |
| rank vs row_number | 并列峰值时，rank保留所有并列第一，row_number只取一个 |

检查项：

  • 表格中每个考点都在当前 SQL 中出现过
  • easy 题目至少 3 个考点，medium/hard 至少 4 个考点
  • 考点使用中文描述 + 小写函数名
  • 没有 SQL 中用到的考点被遗漏

八、符号规范​

位置< <= > >= 规则
```sql 代码块内直接使用 < <= > >=
prose 正文中使用 &lt; &lt;= &gt; &gt;= 转义
行内 ` 代码使用 &lt; &lt;= &gt; &gt;= 转义
HTML 标签 (<details>)正常使用，不转义

检查项：

  • prose 正文无裸 < <= 符号
  • 行内代码无裸 < <= 符号
  • 代码块内正常使用 < <=

九、禁止事项清单​

序号禁止项严重程度
1章节编号错误（两个"一、"）🔴 阻断
2常见坑点来自其他业务场景（如外卖文出现"骑手""配送"）🔴 阻断
3举一反三使用通用模板（"增加时间维度对比"等三件套）🔴 阻断
4知识点列出了 SQL 中未使用的考点🟡 严重
5SQL 关键字使用大写（SELECT、FROM 等）🟡 严重
6DDL 缺少 comment🟡 严重
7prose 中出现裸 < <= 符号🟡 严重
8题目背景是通用模板（不点名具体部门/场景）🟡 严重
9逐步推导缺少分步骤（medium/hard 只给一段 SQL）🟢 一般
10frontmatter keywords 过少（< 5个）🟢 一般

十、审稿流程​

  1. 章节检查：确认八段式结构完整，编号正确
  2. 背景检查：确认点名了具体部门 + 业务场景
  3. SQL 检查：确认全部小写、DDL 有 comment、逐步推导分步骤
  4. 坑点检查：逐条确认与题目业务场景一致，无复制粘贴
  5. 举一反三检查：逐条确认包含具体技术做法，无通用模板
  6. 知识点检查：逐条确认对应 SQL 中实际使用的考点
  7. 符号检查：prose 中 < <= 已转义为 &lt; &lt;=
  8. 禁止项复查：逐条确认无禁止事项

最后更新：2026-07-15 参考标准：阿里 ali-05、B站 bilibili 01-08 已修正文章

📱关注公众号

「数据仓库技术」文章同步更新，不错过每一篇干货

微信公众号二维码
💬加群交流

备注「数据仓库技术」加入社群，每日一道大厂SQL真题

交流微信二维码