14.1 表结构设计范式：三大范式与反范式设计选型

表结构设计的好坏，往往在数据量达到一定级别后才暴露问题，但那时再改结构代价就大了。设计范式是一套经过验证的规则，用来减少数据冗余、避免更新异常。但范式不是教条，实际业务中经常需要反范式来换取查询性能。这一节的目标是让你既能理解范式保护的是什么，又能在合适的时候果断打破它。

14.1.1 第一范式（1NF）：确保每列的原子性

第一范式的核心要求只有一条：表中的每一列都不可再分，即字段值是原子的。

什么叫“不可再分”？看一下这个反例就够了：

-- 违反 1NF 的设计
CREATE TABLE student (
    id       INT PRIMARY KEY,
    name     VARCHAR(50),
    contacts VARCHAR(200)   -- 存储 "手机号,邮箱,家庭住址"
);

contacts 列把多个信息塞进一个字段，查询某个学生的邮箱要用 SUBSTRING_INDEX(contacts, ',', 2)，改手机号还要处理逗号分隔。更麻烦的是，无法在这个字段上建索引去高效搜索“所有邮箱后缀为 @gmail.com 的学生”。这就是典型的违反原子性。

修正方法很直接，拆成独立字段：

CREATE TABLE student (
    id       INT PRIMARY KEY,
    name     VARCHAR(50),
    phone    VARCHAR(20),
    email    VARCHAR(100),
    address  VARCHAR(200)
);

不过要注意，原子性本身也是相对的。比如地址字段，要不要再拆成省、市、区？如果你的业务中 99% 的查询都是拿整个地址去展示，那就没必要拆；如果经常需要按城市做统计过滤，拆成独立字段就更合理。原子性的边界由查询需求决定，不是拆分得越细越好。

14.1.2 第二范式（2NF）：消除非主键列对主键的部分依赖

第二范式在第一范式的基础上，加了一条：非主键列必须完全依赖于整个主键，而不能只依赖于主键的一部分。 这句话主要针对复合主键的场景。

看一个典型的反例：

-- 复合主键：(student_id, course_id)
CREATE TABLE score (
    student_id   INT,
    course_id    INT,
    course_name  VARCHAR(100),    -- 课程名称
    score        DECIMAL(5,2),
    PRIMARY KEY (student_id, course_id)
);

在这个表里，course_name 只依赖于 course_id，与 student_id 无关。这会导致什么问题？

数据冗余：同一个课程被多个学生选修，course_name 就要重复存储几十上百次。
更新异常：如果课程改了名字，需要更新所有关联行，漏掉一条就会数据不一致。
删除异常：如果某门课暂时没有学生选修，删掉最后一条成绩记录时，这门课的名字信息也一起消失了。

修正方案是拆表，让每个非主键列只依赖于完整的主键：

-- 课程表，主键是 course_id
CREATE TABLE course (
    course_id   INT PRIMARY KEY,
    course_name VARCHAR(100)
);

-- 成绩表，主键仍是复合主键，但只存分数
CREATE TABLE score (
    student_id INT,
    course_id  INT,
    score      DECIMAL(5,2),
    PRIMARY KEY (student_id, course_id)
);

在实际项目中，绝大部分表都使用单列自增主键，天然满足第二范式。所以这条规则虽然考试常见，但真正需要处理的情况多是遗留系统或多对多关联表没拆干净时才会碰到。知道它能帮你识别那些“看起来像多对多，实际混入了实体属性”的表。

14.1.3 第三范式（3NF）：消除非主键列对非主键列的传递依赖

第三范式的规则是：非主键列不能依赖于其他非主键列，必须直接依赖于主键。 换句话说，表里不应该有可以通过其他字段推导出来的字段。

举一个常见的反例：

CREATE TABLE employee (
    emp_id    INT PRIMARY KEY,
    emp_name  VARCHAR(50),
    dept_id   INT,
    dept_name VARCHAR(100)   -- 部门名称
);

这里 dept_name 依赖于 dept_id，而 dept_id 又依赖于主键 emp_id，形成了传递依赖。数据冗余和更新异常同样存在：部门改名要批量更新，某部门暂时无员工时部门信息就存不住。

修正方法同样是拆表：

CREATE TABLE department (
    dept_id   INT PRIMARY KEY,
    dept_name VARCHAR(100)
);

CREATE TABLE employee (
    emp_id   INT PRIMARY KEY,
    emp_name VARCHAR(50),
    dept_id  INT,
    FOREIGN KEY (dept_id) REFERENCES department(dept_id)
);

第三范式在业务开发中非常实用。很多冗余字段都是在“查询方便”的诱惑下加的，但维护成本会随时间迅速上升。尤其是在需要频繁修改的字段上，违反 3NF 的代价很高。如果你真的需要冗余，那应该是经过深思熟虑的反范式设计，而不是无意识的懒省事。

14.1.4 范式的实际价值：你得到的是什么

遵守三大范式，你可以得到三个明确的好处：

减少数据冗余，节省存储空间。虽然磁盘越来越便宜，但冗余的真正代价不在空间，而在维护。
避免更新异常、插入异常、删除异常。范式化设计的表，改一处即可，不用担心遗漏造成不一致。
数据模型清晰，易于理解和扩展。新来的同事看到高度规范化的模型，能快速理清实体和实体间的关系。

但范式也不是没有代价。高度规范化的表意味着：查询时经常需要 JOIN。一个原本可以在单表里直接拿到的结果，现在要关联三四张表，查询 SQL 变复杂，执行效率也可能变差。

14.1.5 反范式设计的场景与选型

反范式指的是在满足业务需求的前提下，故意引入一定程度的冗余，用存储空间和额外的写入维护成本，换取更高的读取性能。

以下场景通常会考虑反范式：

场景一：高频查询，极少更新的字段

比如用户表中经常需要展示“归属部门名称”。如果每次都 JOIN 部门表，在并发高时确实会增加开销。如果部门名称几乎不变，完全可以在用户表冗余一个 dept_name。代价是部门改名时要多更新一张表，但这个运维成本远小于天天几十万次不必要的 JOIN。

场景二：报表和汇总数据

比如订单表中冗余 user_name、product_title，而不是每次查订单列表时都关联用户表和商品表。再比如在帖子表冗余 last_reply_time，避免每次展示论坛版块时都去回复表里 MAX(time)。后一种情况要配合触发器或应用层保证字段更新，但查询性能提升显著。

场景三：分库分表后的关联困难

一旦水平拆分了用户表，他们分散在多个库，跨库 JOIN 几乎不可能完成。这时候你可以在订单表里冗余用户的关键信息（如昵称、头像），即使订单量巨大，也能高效获取。

场景四：缓存延时无法接受的实时查询

有些场景下即使有缓存，也不允许出现数据短暂不一致，又不想每次查都复杂 JOIN。反范式冗余就是一个折中选择。

选型原则：先范式化，后有节制地反范式

不要一上来就反范式。正确的姿势是：

从第三范式开始设计，确保模型正确、无冗余。
在上线后通过慢查询日志和监控，找到真正的性能瓶颈。
针对那些确实因为 JOIN 而变慢的热点查询，考虑反范式设计。
评估冗余字段的维护成本：它多久更新一次？更新时是否容易保证一致性？如果维护成本远低于性能收益，就可以冗余。
在文档或注释中标记冗余字段及其数据来源，让将来的维护者知道它的“真相”在哪里。

总结一句话：范式帮你少犯错，反范式帮你跑得快。两者不是对立，而是不同阶段和场景下的择优。 理解范式是掌握关系型数据库设计的钥匙，踩准反范式的时机则是区分经验丰富与否的分水岭。