📐 范式与反范式数据库设计面试题

1NF：要求表中每一列都是不可再分的原子值，没有重复的列组。

反例：在订单表中用一个字段 product_ids 存多个商品 ID，如 "1,2,3"，违反 1NF。

2NF：在满足 1NF 的基础上，要求非主属性完全函数依赖于主键，不能只依赖主键的一部分。

主要解决复合主键下的部分依赖问题，避免字段既依赖于整个主键又依赖于主键的一部分。

• 3NF：在 2NF 基础上，要求非主属性不依赖于其他非主属性（消除传递依赖）。
• BCNF：更严格，要求每个非平凡函数依赖 X→Y 中，X 都是超键。

实际 OLTP 项目中通常保证到 3NF，然后根据性能需求做适当反范式处理。

原表：Student(id, name, class_id, class_name, college_name)

• id → class_id
• class_id → class_name, college_name

非主属性 college_name 通过 class_id 间接依赖主键 id，属于传递依赖，违反 3NF。

拆分：

• Student(id, name, class_id)
• Class(class_id, class_name, college_name)

反范式：为了性能或易用性，有意识地引入冗余，牺牲一定的更新成本来减少关联查询。

典型场景：

• 读远多于写，且强依赖 JOIN 的复杂查询。
• 数据量巨大、跨库 JOIN 成本极高。

在订单表中保留 user_name、phone 等冗余字段：

好处

• 查询订单列表时无需 JOIN 用户表，性能更好。
• 保留下单时的快照信息，即使用户改名也不影响历史订单展示。

代价

• 字段冗余，增加存储。
• 修改用户基础信息时，相关订单表字段需要同步更新或接受不一致。

• OLTP：面向事务处理，强调写性能与一致性，建模多采用 3NF。
• OLAP/数仓：面向分析与聚合查询，更倾向维度建模、星型/雪花模型，本质上就是高度反范式化。

更新异常多来自重复数据：一处更新，其他地方忘记更新。

删除异常多来自一行承担多重含义：删除一个概念时误删了另一个。

通过 2NF/3NF 把重复数据拆到独立表，用主外键关联，可以在更新/删除时减少这类问题。

• JOIN 多了会增加查询复杂度、占用更多 CPU 与内存，可能触发临时表、排序等。
• 在高并发场景下，大量复杂 JOIN 会成为数据库瓶颈。

实践中通常：

• 核心交易表偏范式化，保证一致性与简单关系。
• 查询层通过冗余、物化视图、缓存等手段减少 JOIN。

基础表：

• author(id, name, email,...)
• post(id, title, content, author_id, created_at,...)
• tag(id, name)
• post_tag(post_id, tag_id)

可选反范式：

• 在 post 表中冗余 author_name，提升列表页展示性能。
• 在 post 表中缓存 tags 字符串，方便全文检索。

• 跨库 JOIN 成本巨大，因此更倾向反范式设计，尽量把业务所需数据放在同一分片/同一表。
• 但核心约束仍会保持在单库内，如订单与用户关系。

可按以下步骤描述：

1. 从业务域出发画出核心实体与关系（ER 图）。
2. 初步范式化拆分表，避免明显的冗余和异常。
3. 根据访问场景优化，做适当反范式 + 索引设计。
4. 与业务方、后端、数据分析一起评审并迭代。

• 核心稳定字段走标准列，频繁变化字段可以用 JSON 扩展字段存储。
• 对需要过滤/排序的关键字段，考虑从 JSON 抽取到独立列。

可以按照：

1. 初期：严格 3NF，业务简单，JOIN 可接受。
2. 问题：访问模式变复杂、QPS 提升后，JOIN 成为瓶颈。
3. 演进：对一些列表页、统计场景增加冗余字段或汇总表。
4. 效果：关键接口延迟大幅下降，同时通过定时任务/MQ 保持冗余数据可接受的一致性。

• 先范式化，再反范式化——有意识地、局部地冗余。
• 交易核心表优先保证范式和约束；查询/报表层更灵活。
• 任何冗余都要有“维护策略”和“回滚方式”。