数据库三大范式是什么？为什么有时要反范式设计？
简化版
三大范式主要是减少数据冗余和更新异常：第一范式要求字段原子，第二范式要求非主属性完全依赖主键，第三范式要求非主属性不传递依赖主键。反范式是在读性能、历史快照、报表查询等场景下有意保留冗余，但必须有一致性维护策略。
详细版
三大范式可以这样理解：
| 范式 | 核心要求 | 解决的问题 |
|---|---|---|
| 第一范式 | 字段不可再拆，保持原子性 | 一列里塞多个值导致查询困难 |
| 第二范式 | 非主属性完全依赖整个主键 | 联合主键下的部分依赖 |
| 第三范式 | 非主属性不依赖其他非主属性 | 传递依赖导致冗余和更新异常 |
范式的目标是让数据结构更清晰、冗余更少、更新更安全。但互联网业务中经常会反范式，比如订单表冗余商品名称、用户名、店铺名称，避免历史订单展示受商品改名影响，也减少高频 JOIN。
反范式不是乱设计，而是为了明确目标牺牲一部分冗余，换取读性能、查询简单性或历史快照能力。
完整版教学
一、范式解决的是数据异常
范式不是为了让表看起来“学术”，而是为了解决三个问题：
- 插入异常：想插入某个信息，却因为另一个信息还没有而插不进去；
- 更新异常：同一个信息冗余在多处，更新时漏改导致不一致；
- 删除异常：删除一条业务记录时，把仍然需要的信息也删没了。
例如把订单、用户、商品信息全部塞在一张表里，商品名称会在每个订单行里重复。商品改名时，要更新大量历史行，还可能漏掉。这就是范式想避免的问题。
二、第一范式：字段要原子
第一范式要求字段值不可再拆。比如把多个手机号存成：
phone = "138...,139...,137..."这会让查询、索引、校验都很难做。更合理的是拆成用户表和用户手机号表，一行一个手机号。
但原子性要结合业务边界判断。地址是否拆成省市区街道，不是由范式单独决定，而是由业务是否需要按省市统计、筛选、校验来决定。
三、第二范式：不要只依赖联合主键的一部分
第二范式主要针对联合主键。假设选课表主键是 (student_id, course_id)，字段里又放了 student_name。
student_name 只依赖 student_id，不依赖整个联合主键。这就会导致同一个学生选多门课时，姓名重复出现。更好的做法是学生信息放学生表，选课表只保留学生 ID 和课程 ID。
四、第三范式：不要传递依赖
第三范式要求非主属性不要依赖其他非主属性。比如订单表有：
order_id, user_id, user_level, level_discount如果 level_discount 取决于 user_level，而 user_level 又取决于 user_id，就出现传递依赖。折扣规则变更时，订单表里大量数据都可能要更新。
这种规则信息更适合单独放等级规则表，订单表只引用必要 ID 或保存历史快照。
五、为什么实际项目会反范式
范式减少冗余，但查询时可能需要更多 JOIN。对于高频读、低频改、需要历史快照的场景，适度冗余反而更合适：
- 订单冗余商品名称，保证历史订单不受商品改名影响；
- 评论冗余用户昵称，减少列表页 JOIN；
- 报表宽表冗余多个维度，提升查询效率；
- 商品搜索表冗余分类、品牌、标签，方便检索。
关键是：冗余字段必须知道“谁是事实来源”，以及“什么时候同步更新”。
六、反范式的风险怎么控制
反范式最怕一致性失控。常见控制手段：
- 明确主表是数据源，冗余表只是副本；
- 同事务内更新主表和冗余字段；
- 用消息队列或 binlog 异步同步；
- 设置定时校验任务；
- 对历史快照字段明确“不再跟随源数据变化”。
比如订单里的商品名称通常是历史快照，不应该随着商品表改名而变化；而用户资料页里的昵称冗余可能需要同步。
所以反范式字段要先标注语义：它到底是“快照字段”还是“同步副本”。订单商品名是快照，源商品改名后历史订单不变；商品搜索宽表里的品牌名是同步副本，品牌改名后需要通过消息、binlog 或重建索引更新。语义不同，一致性策略也不同。
七、常见误区与追问
| 设计选择 | 收益 | 代价 |
|---|---|---|
| 范式化 | 冗余少、更新安全、结构清晰 | 查询可能需要更多 JOIN |
| 反范式 | 读更快、历史快照更稳定、报表更简单 | 冗余字段需要一致性维护 |
| 宽表汇总 | 分析查询方便 | 更新链路和数据校验更复杂 |
记忆钩子：范式不是“表越多越好”，反范式也不是“字段随便重复”。关键是知道事实来源在哪里，以及冗余字段是否要跟随源数据变化。
举个订单快照例子：商品表里商品名从“基础版会员”改成“标准版会员”，历史订单仍应展示下单时名称。这里订单表冗余 product_name 不是违反设计，而是在保存交易快照；如果 100 万条历史订单都跟着商品名变化，反而破坏了业务事实。
- 误区：满足三大范式的设计一定最好。 范式化能减少异常，但高频列表、历史快照、搜索和报表场景常常需要适度冗余。
- 误区：反范式就是把所有字段放一张表。 反范式是有目标的冗余，不是无边界宽表。
- 误区：第一范式要求所有复合概念都必须拆到最细。 原子性取决于业务是否需要查询、校验和统计该部分，比如地址是否拆省市区要看业务需求。
- 追问：第二范式主要解决什么问题？ 主要解决联合主键下的部分依赖，非主属性不能只依赖联合主键的一部分。
- 追问：第三范式主要解决什么问题？ 主要解决传递依赖，非主属性不应依赖另一个非主属性。
- 追问：反范式一致性怎么保证？ 明确主数据源，同事务同步、消息异步同步、binlog 订阅、定时校验或声明为历史快照不再同步。
八、加强记忆
范式是为了减少冗余和数据异常，反范式是为了性能、快照和查询便利而有意冗余。范式回答“数据应该怎么归一”，反范式回答“为了业务读写要不要复制一份”；真正成熟的设计，是知道什么时候规范化，什么时候冗余，以及如何维护一致性。