数据库范式与反规范化

关系数据库设计的核心在于如何在数据冗余与查询性能之间取得平衡。范式理论指导我们消除冗余、保证一致性，而反规范化则是在特定场景下有意识地引入冗余以换取性能。本文系统讲解函数依赖、三大范式、模式分解理论、反规范化策略，以及在实际项目中如何做出设计取舍。

---

一、为什么需要范式与反规范化

1.1 不规范设计的问题

假设我们用一张大表存储所有订单信息：

order_id	user_id	user_name	user_phone	product_id	product_name	price	quantity
1	1001	张三	1380001	P001	iPhone 15	6999	1
2	1001	张三	1380001	P002	小米14	3999	1
3	1002	李四	1380002	P001	iPhone 15	6999	2

存在的问题：

问题	示例
数据冗余	张三的用户名和手机号在每条订单中重复存储
更新异常	张三改了手机号，需要更新所有相关订单行，遗漏则数据不一致
插入异常	如果没有订单，就无法记录新用户的信息
删除异常	删除了张三的所有订单，张三的用户信息也丢失了

1.2 范式与反规范化的关系

范式化（规范化）             反规范化
    ↓                          ↓
消除数据冗余           ←→    有意引入冗余
保证数据一致性         ←→    提升查询性能
减少更新异常           ←→    增加更新成本
表数量多、JOIN多       ←→    表数量少、JOIN少
写入友好               ←→    读取友好

核心观点：范式不是越高越好，反规范化也不是"反范式"。两者是设计工具，需要根据业务场景选择。

---

二、函数依赖

函数依赖是范式理论的基础，理解函数依赖才能理解范式。

2.1 基本概念

设 R(U) 是属性集 U 上的关系模式，X、Y 是 U 的子集。若对于 R(U) 的任意一个可能的关系 r，r 中不可能存在两个元组在 X 上的属性值相等而在 Y 上的属性值不等，则称 Y 函数依赖于 X，记作 X → Y。

通俗理解：知道了 X 的值，就能唯一确定 Y 的值。

示例：

学号 → 姓名（知道学号就能确定姓名）
学号 → 院系（知道学号就能确定院系）
(学号, 课程号) → 成绩（知道学号和课程号就能确定成绩）

2.2 函数依赖的分类

类型	定义	示例
完全函数依赖	X → Y，且 X 的任何真子集都不决定 Y	(学号, 课程号) → 成绩
部分函数依赖	X → Y，但 X 中存在真子集也决定 Y	(学号, 课程号) → 姓名（学号 alone 就能决定姓名）
传递函数依赖	X → Y，Y → Z，但 Y ↛ X	学号 → 院系 → 院长（院系决定院长，学号通过院系间接决定院长）

完全函数依赖示意：
(学号, 课程号) ──→ 成绩
   ↗          ↗
学号       课程号
（任一单独不能决定成绩）

部分函数依赖示意：
(学号, 课程号) ──→ 姓名
   ↑
学号 ──→ 姓名
（学号单独就能决定姓名，课程号多余）

传递函数依赖示意：
学号 ──→ 院系 ──→ 院长

2.3 码（键）

概念	定义
候选码	能唯一标识一个元组的最小属性集
主码	从候选码中选定的一个，作为主键
主属性	包含在任一候选码中的属性
非主属性	不包含在任何候选码中的属性

示例：

关系模式：R(学号, 姓名, 课程号, 成绩, 院系, 院长)
候选码：(学号, 课程号)
主属性：学号, 课程号
非主属性：姓名, 成绩, 院系, 院长

---

三、三大范式详解

3.1 第一范式（1NF）

定义：关系模式 R 的所有属性都是原子的（不可再分）。

违反 1NF 的示例：

order_id	products
1	iPhone 15, 小米14
2	MacBook Pro

products 字段包含了多个产品，不是原子值，违反 1NF。

满足 1NF 的改造：

order_id	product_name
1	iPhone 15
1	小米14
2	MacBook Pro

1NF 的本质：每个单元格只存一个值。这是关系数据库最基本的要求。

1NF 在实践中的注意点：

• 避免存储 JSON 数组或逗号分隔值：如 "1,2,3" 或 [1,2,3]
• 避免嵌套表结构：每列应该是单一值
• 字符串本身不需要再拆：如 "张三" 不需要拆成姓和名（除非业务需要）

3.2 第二范式（2NF）

定义：在满足 1NF 的基础上，非主属性对候选码完全函数依赖（消除部分函数依赖）。

典型的违反 2NF 场景：

关系模式：R(学号, 课程号, 姓名, 院系, 成绩)
候选码：(学号, 课程号)

(学号, 课程号) ──→ 成绩  ✅ 完全函数依赖
(学号, 课程号) ──→ 姓名  ❌ 部分函数依赖（学号 → 姓名）
(学号, 课程号) ──→ 院系  ❌ 部分函数依赖（学号 → 院系）

满足 2NF 的改造——分解为两个关系模式：

R1(学号, 姓名, 院系)        -- 学号 → 姓名, 学号 → 院系
R2(学号, 课程号, 成绩)       -- (学号, 课程号) → 成绩

对应 SQL：

-- 学生表
CREATE TABLE `t_student` (
    `student_id`   VARCHAR(20) NOT NULL COMMENT '学号',
    `name`         VARCHAR(50) NOT NULL COMMENT '姓名',
    `department`   VARCHAR(50) NOT NULL COMMENT '院系',
    PRIMARY KEY (`student_id`)
) COMMENT '学生表';

-- 选课成绩表
CREATE TABLE `t_score` (
    `student_id`   VARCHAR(20) NOT NULL COMMENT '学号',
    `course_id`    VARCHAR(20) NOT NULL COMMENT '课程号',
    `score`        DECIMAL(5,2) NULL     COMMENT '成绩',
    PRIMARY KEY (`student_id`, `course_id`)
) COMMENT '选课成绩表';

2NF 的本质：一张表中，非主键列必须依赖于整个主键，而不是主键的一部分。在单列主键的表中，天然满足 2NF。

3.3 第三范式（3NF）

定义：在满足 2NF 的基础上，非主属性不传递函数依赖于候选码（消除传递函数依赖）。

典型的违反 3NF 场景：

关系模式：R(学号, 姓名, 院系, 院长)
候选码：学号

学号 → 院系    ✅ 直接依赖
院系 → 院长    → 传递依赖
学号 → 院长    ❌ 通过院系传递依赖

满足 3NF 的改造——分解为两个关系模式：

R1(学号, 姓名, 院系)    -- 学号 → 姓名, 学号 → 院系
R2(院系, 院长)           -- 院系 → 院长

对应 SQL：

-- 学生表（去掉了院长字段）
CREATE TABLE `t_student` (
    `student_id`   VARCHAR(20) NOT NULL COMMENT '学号',
    `name`         VARCHAR(50) NOT NULL COMMENT '姓名',
    `department`   VARCHAR(50) NOT NULL COMMENT '院系',
    PRIMARY KEY (`student_id`)
) COMMENT '学生表';

-- 院系表
CREATE TABLE `t_department` (
    `dept_name`    VARCHAR(50) NOT NULL COMMENT '院系名称',
    `dean`         VARCHAR(50) NOT NULL COMMENT '院长',
    PRIMARY KEY (`dept_name`)
) COMMENT '院系表';

3NF 的本质：非主键列必须直接依赖于主键，不能间接依赖。即"每个非主属性既不部分依赖也不传递依赖于候选码"。

3.4 BC 范式（BCNF）

定义：在满足 3NF 的基础上，每个决定因素都包含候选码。

BCNF 是 3NF 的增强版，处理了 3NF 中"主属性对候选码的部分/传递依赖"问题。

违反 BCNF 的示例：

关系模式：R(学生, 教师, 课程)
语义：一个教师只教一门课，一门课可以有多个教师，一个学生选一门课只对应一个教师
候选码：(学生, 教师) 和 (学生, 课程)

教师 → 课程   （教师决定课程，但教师不是候选码）

教师是决定因素但不是候选码，违反 BCNF。

满足 BCNF 的改造：

R1(学生, 课程)      -- 哪个学生选了哪门课
R2(教师, 课程)      -- 哪个教师教哪门课

BCNF 与 3NF 的区别：3NF 允许主属性对候选码的部分/传递依赖，BCNF 不允许。在实际项目中，满足 3NF 通常已经足够，BCNF 较少遇到。

3.5 各范式关系

1NF（属性原子性）
  ↓  消除部分函数依赖
2NF（非主属性完全函数依赖于候选码）
  ↓  消除传递函数依赖
3NF（非主属性不传递依赖于候选码）
  ↓  每个决定因素都包含候选码
BCNF
  ↓  消除多值依赖
4NF
  ↓  消除连接依赖
5NF

范式	解决的问题	实际重要性
1NF	属性非原子	⭐⭐⭐ 必须满足
2NF	部分函数依赖	⭐⭐⭐ 必须满足
3NF	传递函数依赖	⭐⭐⭐ 几乎必须满足
BCNF	主属性的异常依赖	⭐⭐ 大多数场景 3NF 足够
4NF	多值依赖	⭐ 少见
5NF	连接依赖	⭐ 极少见

---

四、模式分解

模式分解是将一个大的关系模式分解为多个小的关系模式，以消除不良的函数依赖，达到更高的范式级别。

4.1 模式分解的目标

目标	说明
无损连接性	分解后的关系通过自然连接能恢复原来的关系，不丢失信息
依赖保持性	分解后的关系能保持原来的所有函数依赖

无损连接是必须满足的，否则分解后无法还原数据，失去了意义。依赖保持是"尽量满足"的，有时无法同时满足无损连接和依赖保持。

4.2 无损连接的判定

方法一：Chase 算法（表格法）

步骤：

1. 构造一张表，行对应分解后的各关系模式，列对应原关系模式的所有属性
2. 若属性在对应关系模式中出现，填 aᵢ，否则填 bᵢⱼ
3. 对每个函数依赖 X → Y，若有两行在 X 列上相同，则将 Y 列也改为相同（a 优先于 b）
4. 若某一行全部变为 a，则为无损分解

示例：

R(A, B, C, D)
函数依赖：A → C, C → B
分解：R1(A, C), R2(B, C, D)

初始表：

	A	B	C	D
R1	a1	b12	a3	b14
R2	b21	a2	a3	a4

应用 A → C：R1 和 R2 在 A 列不同（a1 ≠ b21），不做修改。
应用 C → B：R1 和 R2 在 C 列相同（a3 = a3），将 B 列改为相同：b12 → a2。

修改后：

	A	B	C	D
R1	a1	a2	a3	b14
R2	b21	a2	a3	a4

没有一行全为 a，所以这个分解不是无损分解。

方法二：定理法（适用于分解为两个关系模式）

若 R 分解为 R1 和 R2，则分解为无损连接的充要条件是：

(R1 ∩ R2) → (R1 - R2) 或 (R1 ∩ R2) → (R2 - R1)

即 R1 和 R2 的交集能函数决定 R1 和 R2 的差集。

示例：

R(A, B, C, D)
函数依赖：A → B, B → C, C → D
分解：R1(A, B), R2(B, C, D)

R1 ∩ R2 = {B}
R1 - R2 = {A}
R2 - R1 = {C, D}

B → A？不在函数依赖集中 ❌
B → {C, D}？B → C 且 C → D，由传递律 B → {C, D} ✅

所以是无损分解 ✅

4.3 保持函数依赖的判定

检查分解后的关系模式中，所有原函数依赖是否都能在某个关系模式中被逻辑蕴含。

简化方法：对每个函数依赖 X → Y，检查 X⁺（X 的属性闭包）是否在某个关系模式中包含 Y。

R(A, B, C, D)
函数依赖：A → B, B → C, C → D
分解：R1(A, B), R2(B, C, D)

A → B：在 R1 中 ✅
B → C：在 R2 中 ✅
C → D：在 R2 中 ✅

保持函数依赖 ✅

4.4 三种分解策略

策略	保证	可能牺牲
达到 3NF 的无损连接分解	无损连接	可能不保持函数依赖
达到 3NF 的依赖保持分解	保持函数依赖	可能不满足无损连接
达到 3NF 的既无损又保持分解	两者都保证	—

实际项目中：优先保证无损连接，其次尽量保持函数依赖。3NF 分解几乎总能找到既无损又保持的方案。

4.5 3NF 分解算法

算法：合成法（达到 3NF 且保持函数依赖）

1. 求 F 的最小函数依赖集 Fₘ
2. 对 Fₘ 中每个函数依赖 X → Y，将 X ∪ Y 作为一个关系模式
3. 若某个关系模式被另一个包含，则去掉被包含的
4. 若最终分解不包含候选码，则添加一个仅含候选码的关系模式

算法：分解法（达到 3NF 且无损连接）

1. 先用合成法得到保持函数依赖的分解
2. 若分解中已包含候选码，则已是无损分解
3. 若不包含候选码，添加一个仅含候选码的关系模式

示例：

R(A, B, C, D, E)
函数依赖：A → B, B → C, AC → D, D → E
候选码：A（因为 A⁺ = {A, B, C, D, E}）

最小函数依赖集：A → B, B → C, AC → D, D → E

合成法：
R1(A, B)     -- A → B
R2(B, C)     -- B → C
R3(A, C, D)  -- AC → D
R4(D, E)     -- D → E

检查候选码 A：R1 包含 A，且 A → B 在 R1 中，所以已包含候选码。

最终分解：R1(A, B), R2(B, C), R3(A, C, D), R4(D, E)

---

五、反规范化

反规范化是为了提高查询性能，有意识地在满足范式的基础上引入数据冗余。

5.1 为什么需要反规范化

完全满足 3NF 的数据库设计：

查询"某学生的成绩及所在院系"：
SELECT s.name, sc.score, d.dean
FROM t_student s
JOIN t_score sc ON s.student_id = sc.student_id
JOIN t_department d ON s.department = d.dept_name
WHERE s.student_id = 'S001';

需要 3 表 JOIN，在大数据量下性能较差。

反规范化后：

在成绩表中冗余存储院系信息：
SELECT name, score, dean
FROM t_score_denorm
WHERE student_id = 'S001';

只需查 1 张表，性能大幅提升。

5.2 反规范化的常见策略

策略一：冗余列（最常用）

在子表中冗余存储父表的常用查询字段：

-- 范式设计：订单表只有 user_id
CREATE TABLE `t_order` (
    `id`       BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `user_id`  BIGINT UNSIGNED NOT NULL,
    `amount`   DECIMAL(10,2)   NOT NULL,
    PRIMARY KEY (`id`),
    KEY `idx_user_id` (`user_id`)
);

-- 反规范化：冗余 user_name，避免 JOIN 用户表
CREATE TABLE `t_order` (
    `id`         BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `user_id`    BIGINT UNSIGNED NOT NULL,
    `user_name`  VARCHAR(64)     NOT NULL,  -- 冗余字段
    `amount`     DECIMAL(10,2)   NOT NULL,
    PRIMARY KEY (`id`),
    KEY `idx_user_id` (`user_id`)
);

适用场景：

• 查询频率远高于更新频率
• 冗余字段很少变化（如用户名、类别名称）
• JOIN 带来的性能开销显著

维护方式：

-- 用户名变更时，同步更新所有订单
UPDATE `t_order` SET `user_name` = '新名字' WHERE `user_id` = 1001;

-- 或通过消息队列异步更新

策略二：预计算列（派生列）

将需要计算的字段预先存储：

-- 范式设计：订单金额和数量分开存储，需要时计算
CREATE TABLE `t_order` (
    `id`       BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `amount`   DECIMAL(10,2)   NOT NULL COMMENT '单价',
    `quantity` INT             NOT NULL COMMENT '数量',
    PRIMARY KEY (`id`)
);
-- 查询总价：SELECT amount * quantity FROM t_order;

-- 反规范化：预存总价
CREATE TABLE `t_order` (
    `id`          BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `amount`      DECIMAL(10,2)   NOT NULL COMMENT '单价',
    `quantity`    INT             NOT NULL COMMENT '数量',
    `total_price` DECIMAL(10,2)   NOT NULL COMMENT '总价 = 单价 × 数量',  -- 冗余
    PRIMARY KEY (`id`)
);

也可以使用 MySQL 生成列（Generated Column）自动维护：

CREATE TABLE `t_order` (
    `id`          BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `amount`      DECIMAL(10,2)   NOT NULL COMMENT '单价',
    `quantity`    INT             NOT NULL COMMENT '数量',
    `total_price` DECIMAL(12,2)   AS (`amount` * `quantity`) STORED COMMENT '总价（生成列）',
    PRIMARY KEY (`id`)
);

策略三：汇总表

对频繁的统计查询，预先计算并存储汇总结果：

-- 实时统计（慢）
SELECT `user_id`, COUNT(*) AS order_count, SUM(`amount`) AS total_amount
FROM `t_order`
WHERE `create_time` >= '2026-01-01'
GROUP BY `user_id`;

-- 反规范化：汇总表
CREATE TABLE `t_user_order_summary` (
    `user_id`       BIGINT UNSIGNED NOT NULL COMMENT '用户ID',
    `stat_date`     DATE            NOT NULL COMMENT '统计日期',
    `order_count`   INT             NOT NULL DEFAULT 0 COMMENT '订单数',
    `total_amount`  DECIMAL(14,2)   NOT NULL DEFAULT 0 COMMENT '总金额',
    PRIMARY KEY (`user_id`, `stat_date`)
) COMMENT '用户订单汇总表';

-- 定时任务更新汇总数据
INSERT INTO `t_user_order_summary` (`user_id`, `stat_date`, `order_count`, `total_amount`)
SELECT `user_id`, DATE(`create_time`), COUNT(*), SUM(`amount`)
FROM `t_order`
WHERE `create_time` >= '2026-01-01'
GROUP BY `user_id`, DATE(`create_time`)
ON DUPLICATE KEY UPDATE
    `order_count` = VALUES(`order_count`),
    `total_amount` = VALUES(`total_amount`);

策略四：合并一对多关系

将子表的部分数据合并到父表：

-- 范式设计：用户表 + 用户详情表
CREATE TABLE `t_user` (
    `id`   BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(64)     NOT NULL,
    PRIMARY KEY (`id`)
);

CREATE TABLE `t_user_detail` (
    `user_id`    BIGINT UNSIGNED NOT NULL,
    `bio`        TEXT            NULL,
    `avatar_url` VARCHAR(255)    NULL,
    PRIMARY KEY (`user_id`)
);

-- 反规范化：合并为一张表（当详情总是和主表一起查时）
CREATE TABLE `t_user` (
    `id`         BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `name`       VARCHAR(64)     NOT NULL,
    `bio`        TEXT            NULL,
    `avatar_url` VARCHAR(255)    NULL,
    PRIMARY KEY (`id`)
);

适用场景：

• 一对一关系，且几乎总是一起查询
• 子表字段不多，合并后不会导致主表过宽

策略五：多值属性横向展开

将行转列，减少表的数量：

-- 范式设计：EAV 模型（属性-值对）
CREATE TABLE `t_user_attr` (
    `user_id` BIGINT UNSIGNED NOT NULL,
    `attr_key`   VARCHAR(50)  NOT NULL,
    `attr_value` VARCHAR(255) NULL,
    PRIMARY KEY (`user_id`, `attr_key`)
);
-- 查询：需要多次 JOIN 或行转列

-- 反规范化：固定列
CREATE TABLE `t_user` (
    `id`      BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `name`    VARCHAR(64)     NOT NULL,
    `phone`   VARCHAR(20)     NULL,
    `email`   VARCHAR(128)    NULL,
    `address` VARCHAR(255)    NULL,
    PRIMARY KEY (`id`)
);

何时用 EAV 何时用固定列：属性固定且数量少 → 固定列；属性动态且数量不确定 → EAV 或 JSON 字段。

5.3 反规范化的代价与维护

代价	说明
数据不一致风险	冗余字段更新时可能遗漏，导致数据不一致
更新成本增加	一个变更可能需要更新多张表/多行记录
存储空间增加	冗余数据占用额外空间
维护复杂度增加	需要额外的同步逻辑确保一致性

维护冗余数据一致性的方案：

方案	说明	适用场景
同步更新	在同一个事务中更新所有冗余数据	冗余数据量少、更新频率低
消息队列异步更新	发送消息到 MQ，消费者异步更新冗余数据	对实时性要求不苛刻
定时任务批量同步	定时检查并修复不一致的冗余数据	对最终一致性可接受
触发器	数据库触发器自动维护冗余数据	简单场景，不推荐复杂逻辑

5.4 反规范化的决策流程

是否需要反规范化？
    |
    v
查询性能是否是瓶颈？（通过 EXPLAIN / 慢查询日志确认）
    |
    +-- 否 --> 保持范式设计
    |
    +-- 是 --> 能否通过索引优化解决？
                |
                +-- 能 --> 优先加索引
                |
                +-- 不能 --> 冗余字段的更新频率？
                              |
                              +-- 高频更新 --> 不建议反规范化
                              |
                              +-- 低频更新 --> 反规范化，并确保有数据同步机制

---

六、实战：电商系统数据库设计

6.1 范式化设计（3NF）

-- 用户表
CREATE TABLE `t_user` (
    `id`          BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `user_name`   VARCHAR(64)     NOT NULL,
    `phone`       VARCHAR(20)     NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `uk_user_name` (`user_name`)
) COMMENT '用户表';

-- 商品表
CREATE TABLE `t_product` (
    `id`          BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `product_no`  VARCHAR(32)     NOT NULL,
    `name`        VARCHAR(128)    NOT NULL,
    `category_id` BIGINT UNSIGNED NOT NULL COMMENT '品类ID',
    `price`       DECIMAL(10,2)   NOT NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `uk_product_no` (`product_no`),
    KEY `idx_category` (`category_id`)
) COMMENT '商品表';

-- 品类表（消除传递依赖：商品 → 品类ID → 品类名称）
CREATE TABLE `t_category` (
    `id`   BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(64)     NOT NULL,
    PRIMARY KEY (`id`)
) COMMENT '品类表';

-- 订单表
CREATE TABLE `t_order` (
    `id`          BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `order_no`    VARCHAR(32)     NOT NULL,
    `user_id`     BIGINT UNSIGNED NOT NULL,
    `status`      TINYINT         NOT NULL DEFAULT 0,
    `total_amount` DECIMAL(12,2)  NOT NULL DEFAULT 0,
    `create_time` DATETIME        NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (`id`),
    UNIQUE KEY `uk_order_no` (`order_no`),
    KEY `idx_user_id` (`user_id`)
) COMMENT '订单表';

-- 订单明细表（消除部分依赖：订单ID + 商品ID → 数量、单价）
CREATE TABLE `t_order_item` (
    `id`          BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
    `order_id`    BIGINT UNSIGNED NOT NULL,
    `product_id`  BIGINT UNSIGNED NOT NULL,
    `quantity`    INT             NOT NULL DEFAULT 1,
    `unit_price`  DECIMAL(10,2)   NOT NULL,
    PRIMARY KEY (`id`),
    KEY `idx_order_id` (`order_id`),
    KEY `idx_product_id` (`product_id`)
) COMMENT '订单明细表';

6.2 反规范化优化

针对高频查询场景，适度引入冗余：

-- 优化1：订单表冗余 user_name（避免查询订单时 JOIN 用户表）
ALTER TABLE `t_order`
    ADD COLUMN `user_name` VARCHAR(64) NOT NULL DEFAULT '' AFTER `user_id`;

-- 优化2：订单明细冗余 product_name（避免查询明细时 JOIN 商品表）
ALTER TABLE `t_order_item`
    ADD COLUMN `product_name` VARCHAR(128) NOT NULL DEFAULT '' AFTER `product_id`;

-- 优化3：商品表冗余 category_name（避免查询商品时 JOIN 品类表）
ALTER TABLE `t_product`
    ADD COLUMN `category_name` VARCHAR(64) NOT NULL DEFAULT '' AFTER `category_id`;

-- 优化4：订单汇总表（避免实时统计大量数据）
CREATE TABLE `t_order_summary` (
    `stat_date`    DATE            NOT NULL,
    `order_count`  INT             NOT NULL DEFAULT 0,
    `total_amount` DECIMAL(14,2)   NOT NULL DEFAULT 0,
    PRIMARY KEY (`stat_date`)
) COMMENT '订单日汇总表';

6.3 查询对比

-- 范式设计：查询订单列表需要 3 表 JOIN
SELECT o.`order_no`, u.`user_name`, o.`total_amount`, o.`create_time`
FROM `t_order` o
JOIN `t_user` u ON o.`user_id` = u.`id`
WHERE o.`status` = 1
ORDER BY o.`create_time` DESC
LIMIT 20;

-- 反规范化：只需查 1 张表
SELECT `order_no`, `user_name`, `total_amount`, `create_time`
FROM `t_order`
WHERE `status` = 1
ORDER BY `create_time` DESC
LIMIT 20;

---

七、范式与反规范化的选择原则

7.1 决策矩阵

场景	推荐策略
OLTP 系统（高并发写入）	优先满足 3NF，减少更新异常
OLAP 系统（大量复杂查询）	适度反规范化，用空间换时间
读写比 > 10:1	考虑冗余列和汇总表
读写比 < 3:1	优先范式化
数据一致性要求极高（金融）	严格范式化，避免冗余
数据一致性可接受最终一致	可适度反规范化
单表数据量 < 百万	范式化，JOIN 性能可接受
单表数据量 > 千万	考虑反规范化 + 分库分表

7.2 黄金法则

1. 设计时先满足 3NF，这是起点而非终点
2. 基于真实查询模式反规范化，而非凭想象
3. 每引入一个冗余字段，都要有对应的维护方案
4. 索引优化优先于反规范化——很多时候加索引就能解决性能问题
5. 量化评估——反规范化前后对比查询性能，确保收益大于代价
6. 文档化冗余关系——记录哪些字段是冗余的、维护方式是什么，避免后续维护时遗漏

---

八、总结

8.1 核心要点速查

1. 1NF：属性原子性，每个单元格只存一个值
2. 2NF：消除部分函数依赖，非主属性完全依赖于候选码
3. 3NF：消除传递函数依赖，非主属性直接依赖于候选码
4. BCNF：每个决定因素都包含候选码（3NF 的增强版）
5. 模式分解必须保证无损连接，尽量保持函数依赖
6. 反规范化是有意识引入冗余以提升查询性能，不是"反范式"
7. 反规范化的前提：查询性能确实是瓶颈，且索引优化无法解决
8. 反规范化的代价：数据一致性维护成本、更新成本、存储成本
9. 先 3NF 后反规范化：设计时先满足范式，再根据性能需求反规范化
10. OLTP 优先范式化，OLAP 优先反规范化

---

GitHub
Gitee
微信公众号
掘金
知乎