企业官网建设流程全解析

“数据库三范式”这几个字，几乎是每个写后端的人都绕不开的一道坎。我最早是在一次面试里被问到的：对方甩过来一张订单表，让我说说设计上有什么问题。我盯着看了半天，凭直觉指出“商品名称不该塞在订单表里”，但具体为什么不该、该怎么改，说不出个所以然。后来把三范式真正吃透才明白，这套理论与其说是一份建表规范，不如说是一把尺子——它不直接告诉你表该长什么样，它告诉你一张表里到底混进了多少种“本不该住在一起的事实”。

这些年做业务系统的表设计，我对三范式的态度摇摆过好几轮。刚入行时把它当金科玉律，见一张表恨不得拆成五张，结果一个列表查询 join 出七八张表，接口响应慢得让人怀疑人生；后来转做查询性能和报表方向，又开始无脑冗余字段，恨不得所有数据塞进一张宽表，结果一次商品调价，历史订单金额全被改写了。真正稳定下来的判断是：范式负责把数据之间的关系理清楚，反范式负责把查询路径缩短，这是两个层面的问题，分开看，冲突就少了一大半。

这篇内容适合谁看？如果你正在准备面试，需要把 1NF、2NF、3NF 讲到能让面试官点头；如果你正在设计第一版表结构，拿不准哪些字段该拆出去、哪些该留在原地；或者你接手了一个“一条 SQL join 七张表”的老系统，想搞明白当初为什么要这么设计——都值得往下读。我会拿一张订单表从头推到尾，把每一步的取舍理由、方言无关的建表 SQL、以及我自己踩过的坑都摆出来，尽量做到看完就能照着改。

1. 三范式到底在解决什么问题

1.1 从一次数据对不上的事故说起

几年前我接手过一个商品管理模块，表结构大概是这样的：一张goods表里塞了商品 ID、商品名称、分类 ID、分类名称、供应商 ID、供应商联系人、供应商电话，甚至还有“该供应商下共有多少商品”这样的统计字段。表的行数不多，十万出头，查询确实快，一个select *就能把列表页需要的东西全捞出来，当时设计的人还挺得意。

问题出在供应商换联系人的时候。运营在后台改了一个供应商的电话，结果只改掉了这个供应商下第一条商品记录的电话，其余九百多条商品记录里的电话还是旧的。客服按旧号码打过去，打了一整天没人接。事后排查，根因就是“供应商电话”这一个事实，在表里存了九百多份副本，更新语句忘了加where supplier_id = ?，只命中了一行。

这件事把三范式要解决的三类异常完整地演示了一遍：

• 更新异常：同一份事实存了多份，改的时候只改了一部分，数据自相矛盾。
• 插入异常：想录入一个新供应商，但对方还没有商品，此时没有商品 ID，主键凑不出来，这条信息就录不进去。
• 删除异常：把某个供应商的最后一件商品下架删除，供应商的联系方式跟着一起消失了，可这个供应商本身还在合作。

三范式的本质，就是通过“一份事实只存一个地方”这条原则，把这三类异常从根上掐掉。它不是什么高深的理论，更像是数据库设计领域的“单一事实来源”原则——你在微服务里讲单一职责，在配置管理里讲唯一配置源，在表设计里就是范式。

1.2 函数依赖：读懂范式的底层语言

想真正理解三个范式，绕不开“函数依赖”这个概念。很多人背了定义却不会用，是因为没把它翻译成人话。

所谓 A 函数决定 B（记作 A → B），意思是：只要 A 的值确定了，B 的值就唯一确定了。学号定了，姓名就定了；身份证号定了，出生日期就定了；订单号定了，下单时间就定了。反过来，姓名定不了学号，因为可能重名。

把这个概念套到表上，一张表的所有字段之间会形成一张依赖关系网。三范式做的事情，就是拿剪刀把这张网里“不该由非主键字段决定的依赖”剪断，让每条依赖都指向候选键。

这里有个容易混淆的点：主键决定所有字段，这是天然成立的，不算问题。真正的问题是那些“非主键字段决定另一个非主键字段”的依赖，以及“主键的一部分就能决定某个字段”的依赖。第一范式管的是字段本身能不能再分，第二范式管的是主键的一部分能不能决定别的字段，第三范式管的是非主键字段之间能不能互相决定。

用一句话概括三个范式的递进关系：1NF 要求每个格子只放一个值，2NF 要求每行描述一个完整的主语，3NF 要求每列只描述这个主语本身、不捎带别人的事。

1.3 范式设计的收益与代价

把表拆到 3NF，收益是实打实的：更新只改一处不会漏，插入不受主键凑不齐的限制，删除不会误伤无关信息，存储也省了——供应商电话从存九百份变成存一份。数据一致性由结构保证，而不是靠开发人员每次写 SQL 时记着“记得同步更新那一列”。

代价同样实打实。原本一条select能出结果，拆完之后要 join 三张表；原本改一个字段一条update，拆完之后可能要动两张表还得包在事务里；原本新人看一眼表结构就懂，拆完之后得画个 ER 图才能理清关系。

我见过一些团队走极端，把一个业务模块拆出二十多张表，字段最多的表只有五列，结果任何一个稍微复杂的查询都要 join 五张以上，写 SQL 的时间比写业务逻辑还长。也见过反过来的，所有东西一张宽表，上线三个月数据就开始对不上。这两种我都认为是设计失败——前者忽略了查询成本，后者忽略了维护成本。

我的判断标准很朴素：核心业务实体按 3NF 拆，查询视图按需求冗余。交易、账户、库存这类对一致性极度敏感的表，严格遵守范式；列表页、报表、看板这类读多写少的场景，用冗余字段或者物化视图换查询性能。这个思路在后面第 6 章会展开讲。

2. 第一范式：字段的原子性到底怎么理解

2.1 原子性不是“越小越好”

第一范式的标准表述是：所有字段都必须是原子性的，不可再分。这句话最容易被误解成“字段拆得越细越好”，于是有人把地址拆成省、市、区、街道、门牌号五列，把姓名拆成姓和名两列，甚至把手机号拆成前三位、中间四位、后四位。这就跑偏了。

原子性的真正含义是在当前的业务语境下，这个字段不再需要被数据库层面拆开来单独使用。判断标准不是“它还能不能分”，而是“我要不要按它的某一部分做查询、统计、约束”。

举个具体的：地址字段。如果你的系统要做“按城市统计订单量”，那城市必须单独成列，否则你只能like '%杭州%'去模糊匹配，既走不了索引，又会把“杭州路”这种街道名误算进去。但如果你的系统只是把地址打印在快递单上，从不按地区做任何筛选和聚合，那一整段地址存一个varchar(200)完全符合 1NF，硬拆反而是过度设计。

再比如手机号。存成13812345678是一个原子值，符合 1NF；存成138-1234-5678加了分隔符，严格来说也不算违反 1NF，因为它作为一个整体仍然只表达一个语义，只是带了格式。真正违反 1NF 的是把手机号和座机号塞进同一个字段写成13812345678,0571-88888888，因为这时候你没法对这一列做任何有意义的约束和索引。

2.2 违反 1NF 的四种典型写法

我在代码评审和存量系统里见得最多的，是下面这四类：

第一类，多值塞一格。最经典的是tags字段存"数码,家电,促销"，或者contacts字段存"张三:138xxx|李四:139xxx"。这种设计的直接后果是，想查“带促销标签的商品”，只能where tags like '%促销%'，全表扫描，而且促销季这种值也会被误命中。正确做法是拆一张关联表goods_tag(goods_id, tag_id)，一行一个标签。

第二类，把 JSON 当万能挡箭牌。现在很多数据库都支持 JSON 类型，于是有人把所有扩展属性一股脑塞进一个ext_info字段。这在“属性完全不确定、也不需要查询”的场景下是可以接受的，但一旦你需要按 JSON 里的某个 key 做筛选、排序、唯一约束，麻烦就来了。我见过一个系统把订单的支付状态存在 JSON 里，查“待支付订单”时用 JSON 函数提取，QPS 一上来直接把数据库打满。判断标准很简单：这个字段要不要参与查询、排序、约束、关联？要，就老老实实建列；不要，JSON 才是合理选择。

第三类，复合字段混装。比如contact_info同时存姓名和电话，spec同时存颜色和尺码。这种字段的问题在于语义不单一，任何针对其中一部分的操作都得做字符串切割，而字符串切割在 SQL 里既丑陋又低效。

第四类，重复列组。为了规避多值字段，有人建了phone1、phone2、phone3三列。这同样违反 1NF 的精神，因为它本质上是把“一对多”硬编码成了“一对三”，第四个电话就没地方放了。这种情况应该拆子表。

2.3 拆字段的边界判断

给一个我自己在用的判断流程，遇到一个字段拿不准要不要拆，按顺序问三个问题：

1. 这个字段的某一部分，会不会出现在where、group by、order by、join on里？会，就拆。
2. 这个字段的某一部分，需不需要单独加约束（唯一、非空、取值范围）？需要，就拆。
3. 这个字段的某一部分，会不会被单独更新，而其余部分保持不变？会，就拆。

三个问题都是“不会”，那就让它保持整体，别为了理论纯洁性给自己找麻烦。我见过把“备注”字段按句子拆开的，纯属自娱自乐。

注意：拆分字段会带来一个隐性成本——历史数据迁移。线上表加列、回填、双写、切读，这一套流程走下来，小表几小时，大表可能要一周。所以设计阶段的判断比事后补救值钱得多。

3. 第二范式：复合主键下的部分依赖

3.1 部分依赖是怎么产生的

第二范式的前提是“表有复合主键”。如果一张表的主键是单一列（比如自增 ID），那它天然满足 2NF——因为单一主键不存在“一部分”的概念。这一点很多人没搞清楚，导致面试时被追问“你的表用自增主键，还谈什么 2NF”就卡壳了。

部分依赖指的是：复合主键中的某一个字段，单独就能决定某个非主键字段。注意是“单独”，不是“组合”。

举个最小例子。假设有一张选课表，主键是(student_id, course_id)：

这里student_name只依赖student_id，和course_id没关系；course_name只依赖course_id，和student_id没关系。这就是典型的部分依赖。后果是：张三改了名字，所有他选过的课都要更新；新增一门课但还没有人选，课程名就录不进去，因为主键凑不齐。

拆法很直接：把学生信息拆到student表，课程信息拆到course表，原表只保留(student_id, course_id, score)——这三个字段才真正依赖整个复合主键，因为“成绩”是“某个学生选了某门课”这件事的属性，单独拿学生或单独拿课程都确定不了成绩。

3.2 代理键让 2NF 问题“消失”了吗

这里要泼一盆冷水。现在绝大多数业务表都用自增 ID 或雪花 ID 做主键，理论上天然满足 2NF，很多人因此觉得 2NF 已经过时了。但问题并没有消失，只是换了个马甲。

看这张表，主键是id：

严格按定义，它满足 2NF。但sku_name和sku_price是不是该存在这里？它们只依赖sku_id，本质上是把商品信息复制进了订单明细。这实际上是一个 3NF 的问题被代理键“掩盖”了。所以判断一张表有没有问题，不能只看它满不满足 2NF 的字面定义，要看它内部有没有“非主键字段只依赖另一个非主键字段”的情况。

我个人的经验是：别纠结范式的编号，去找表里的“依赖链”。找出所有A → B的关系（A、B 都是非主键字段），凡是存在的，就问一句“B 是不是应该跟着 A 走”。这个动作比背定义管用十倍。

3.3 业务主键和代理键怎么选

既然聊到主键，这里插一个实际工作中经常纠结的问题：用业务字段做主键（比如身份证号、订单号），还是用无意义的自增 ID。

用业务主键的好处是天然唯一、少一层映射、语义清晰；坏处是业务规则可能变——手机号会换、身份证可能升位、订单号规则可能调整，一旦主键要改，所有引用它的外键都得跟着动，这在数据量大的系统里是灾难。

用代理键的好处是稳定、紧凑（bigint占 8 字节，比varchar(32)的订单号省得多）、索引效率高；坏处是多一层无意义字段，业务唯一性得靠额外加唯一索引来保证。

我的选择：除非是纯关联表（比如goods_tag），否则一律用代理键做主键，业务唯一字段加唯一索引。这样主键永远不变，外键关系稳定，唯一性约束也一分不少。顺便提一句，MySQL 的 InnoDB 里二级索引存的是主键值，如果主键用varchar(32)的订单号，每个二级索引都得多存 32 字节，索引体积和回表成本都会上去，这个在第 4 章会具体算一笔账。

4. 第三范式：传递依赖怎么识别和切断

4.1 传递依赖的判定方法

第三范式要求：非主键字段之间不能存在依赖关系，也就是不能出现A → B → C这种传递链。

判定方法不用想得太复杂，拿张纸把表的所有字段列出来，然后对每个非主键字段问一句：“这个字段是直接描述主键的，还是描述另一个非主键字段的？”只要答案是后者，就存在传递依赖。

回到开头那个商品表的例子。supplier_phone描述的不是商品，而是供应商；category_name描述的不是商品，而是分类。这两个字段都该搬走。这个判定动作，比背“传递依赖”的定义有效得多。

4.2 订单表的完整拆解实操

下面用一个完整的订单场景走一遍，从一张“什么都有”的表拆到 3NF。这是我自己在带新人时用的标准案例。

初始宽表设计：

create table order_wide ( order_id bigint primary key, order_no varchar(32), user_id bigint, user_name varchar(32), user_phone varchar(20), user_address varchar(200), sku_id bigint, sku_name varchar(100), sku_price decimal(10,2), sku_category varchar(50), qty int, total_amount decimal(10,2), create_time datetime );

问题一目了然：一个订单里有多个商品怎么办？只能建多行，于是order_no、user_name、user_address全部重复。用户改了收货地址，历史订单要跟着变（虽然业务上可能不希望变，这是另一回事）。这就是典型的“多种事实混在一张表”。

第一步，拆主从表（解决 1NF 的多值问题）：

create table orders ( order_id bigint primary key, order_no varchar(32) not null, user_id bigint not null, total_amount decimal(10,2) not null, create_time datetime not null, unique key uk_order_no (order_no) ); create table order_item ( item_id bigint primary key, order_id bigint not null, sku_id bigint not null, qty int not null, key idx_order_id (order_id) );

第二步，处理传递依赖（满足 3NF）：user_name、user_phone只依赖user_id，搬到user表；sku_name、sku_price、sku_category只依赖sku_id，搬到sku表。sku_category又只依赖分类，理论上还能再拆一层分类表。

create table users ( user_id bigint primary key, user_name varchar(32) not null, phone varchar(20) ); create table category ( category_id bigint primary key, category_name varchar(50) not null ); create table sku ( sku_id bigint primary key, sku_name varchar(100) not null, price decimal(10,2) not null, category_id bigint not null, key idx_category (category_id) );

到这里，结构上完全符合 3NF，每一列都只描述主键本身，没有跨层依赖。

4.3 但订单明细里必须留一份“快照”

上面这套设计有个坑，是纯理论不会告诉你的：商品价格是会变的，而订单一旦成交，价格必须被冻结。

如果订单明细里只存sku_id和数量，展示金额时去sku表查当前价格，那么商品一调价，三年前的历史订单金额全变了，财务对账直接爆炸。所以order_item里必须冗余sku_name和unit_price。这不是违反范式，这是快照语义——它们描述的是“下单那一刻的商品状态”，而不是“商品当前的状态”，语义上属于订单这个主语自己。

create table order_item ( item_id bigint primary key, order_id bigint not null, sku_id bigint not null, sku_name_snap varchar(100) not null, -- 下单时的名称快照 unit_price_snap decimal(10,2) not null, -- 下单时的单价快照 qty int not null, key idx_order_id (order_id) );

这个细节我认为是三范式的分水岭。能分清“该拆的引用”和“该留的快照”，才算真的会用范式，否则要么拆得订单查不出金额，要么把快照当冗余给优化掉了。

4.4 拆表之后的 JOIN 代价评估

拆到 3NF 的直接后果是查询要 join。很多人到这里就心里没底，其实可以用具体数字算一算，心里就有数了。

假设订单列表页要展示 20 条订单，需要商品名称、用户昵称、分类名称。拆表后的一次查询大概是这样：

select o.order_no, o.total_amount, u.user_name, i.sku_name_snap, c.category_name from orders o join users u on u.user_id = o.user_id join order_item i on i.order_id = o.order_id join sku s on s.sku_id = i.sku_id join category c on c.category_id = s.category_id where o.create_time >= '2024-01-01' order by o.create_time desc limit 20;

如果每个 join 字段都有索引，那么每次 join 都是一次索引查找加一次主键回表，代价大致是 2 到 3 次页访问。5 张表的链路，20 行数据，总共也就几百次页访问，在内存命中率正常的情况下是毫秒级的事。

真正的问题不在这，而在于：如果orders表的过滤条件没有走索引，或者order_item的order_id忘了建索引，那这条 SQL 就会退化成嵌套循环全表扫描，几百万行的表上直接几十秒。所以范式本身不背性能的锅，索引设计和执行计划才是。我处理过的“慢查询”案例里，九成以上是缺索引或者索引失效，只有极少数是“表拆得太碎”。

反过来算一笔存储账。假设users表 100 万行，如果把user_name（平均 12 字节）冗余到 1000 万行的orders表里，多占的存储是 1000 万 × 14 字节（含长度位）≈ 140MB，加上索引可能接近 200MB。看起来不多，但如果冗余的是user_address（平均 60 字节），就是 700MB 起步，而且每次用户改地址都得同步更新历史订单，这个一致性维护成本远高于省下的那点 join。

提示：评估要不要拆，别凭感觉。把行数、字段平均长度、查询频率三个数写下来，估算一下存储和 IO，结论往往和直觉相反。

5. 更高范式：BCNF 与 4NF 的边界在哪

5.1 BCNF 比 3NF 严在哪里

3NF 允许一种特殊情况：主属性依赖于非超键的候选键。这个说法太绕，直接上例子。

经典的“学生-课程-教师”场景：一个学生选一门课，只对应一个任课教师；一个教师只教一门课。表结构是(student, course, teacher)，业务约束是(student, course) → teacher且teacher → course。

这张表满足 3NF，因为course是主属性（它是候选键的一部分），主属性对候选键的依赖在 3NF 里是允许的。但它违反 BCNF，因为teacher → course中的teacher不是超键。

违反的后果是什么？假设“王老师”从教“数学”改成教“物理”，你要更新所有teacher = '王老师'的行，漏一行数据就不一致；假设某个老师新开了一门课但还没有学生选，这门课的信息录不进去，因为student凑不出来。

BCNF 的处理方式是继续拆：teacher_course(teacher, course)和student_teacher(student, teacher)。这样每个决定因素都是超键，问题消失。

那实际工作中要不要管 BCNF？我的答案是：绝大多数业务表用代理键做主键之后，天然满足 BCNF，不用专门操心。真正需要关注 BCNF 的场景，是那些用纯业务字段组成复合主键的表，比如权限系统里的(role_id, permission_id)、库存系统里的(warehouse_id, sku_id)。这类表在设计时多想一步，能省掉后面的麻烦。

5.2 4NF 和 5NF 什么时候才需要关心

4NF 处理的是多值依赖，5NF 处理的是连接依赖。这两个听起来吓人，但判断方法很朴素：当你在同一张表里塞了两组互相独立的多值属性时，就撞上 4NF 了。

典型例子：一个员工可以掌握多种技能，也可以参与多个项目，技能和项目之间毫无关系。如果塞进一张表(emp_id, skill, project)，那么员工会 3 个技能、参与 4 个项目，就要产生 12 行笛卡尔积。这不仅浪费存储，更新时还极易出错。正确做法是拆成emp_skill和emp_project两张表。

5NF 更罕见，一般只在“三元关系能否无损分解成多个二元关系”的场景下才被提及，实际业务开发中几乎碰不到。我的态度很明确：1NF 到 3NF 是必须掌握的日常工具，BCNF 是需要理解的边界知识，4NF 知道什么情况会撞上就够了，5NF 了解概念即可，不必深究。花大量时间研究 5NF 的分解算法，投入产出比极低。

6. 反范式化：什么时候该主动“违规”

6.1 三种值得冗余的场景

严格 3NF 在读多写少的系统里往往不够用。我总结了三类值得主动冗余的场景，判断依据都是“读的次数远大于写的次数，且一致性窗口可以接受”。

第一类，高频列表页的关联字段。商品列表要显示分类名称，如果每次都 join 分类表，QPS 上去之后成本明显。这时候可以在sku表里冗余一个category_name。代价是分类改名时要同步刷一遍商品表，但这个操作一天可能就几次，完全可以接受。要注意的是，冗余字段的更新必须走统一的写入入口，不能散落在各处手动改。

第二类，统计型冗余字段。比如orders表里存item_count（商品件数），避免每次列表页都去order_item里count(*)。这类字段的风险在于并发写入时容易算错，我的做法是：所有变更都在同一个事务里用update orders set item_count = item_count + ?这样的增量方式维护，而不是查一遍再覆盖写，避免并发丢更新。

第三类，历史快照。前面订单例子里的unit_price_snap就是这一类。它的本质不是冗余，而是“把时间维度固化进数据”，属于业务语义要求，不能用范式的眼光去评判。

6.2 冗余之后怎么保证一致性

冗余字段最怕的是“改了一处忘了另一处”。我实践下来有效的做法有三条：

一是收敛写入入口。所有对冗余字段的修改，只能通过一个 service 方法，禁止在多个地方写update。这一点靠代码规范约束，配合 code review 卡住。

二是加对账任务。对关键的冗余字段（比如订单总金额、商品件数），跑一个定时任务做全量或增量比对，发现不一致就告警。我给一个比对 SQL 的思路：

-- 找出 item_count 与实际明细条数不一致的订单 select o.order_id, o.item_count, count(i.item_id) as real_count from orders o left join order_item i on i.order_id = o.order_id where o.create_time >= date_sub(now(), interval 1 day) group by o.order_id, o.item_count having o.item_count <> count(i.item_id);

三是接受最终一致。绝大多数冗余字段不需要强一致，允许几秒到几分钟的延迟。如果业务确实要求强一致（比如账户余额），那就别用冗余字段，老老实实走范式加事务。

6.3 数据仓库和业务库是两套逻辑

这里必须强调一个经常被混淆的点：三范式是面向 OLTP 业务库的设计原则，数据仓库的建模逻辑完全不同。

业务库强调写入正确性、事务一致性、更新不遗漏，所以按 3NF 拆。数据仓库强调查询效率、分析便利，所以走维度建模，星型结构，一张事实表周围挂一圈维度表，甚至直接做成大宽表。在数仓里谈“这张表不符合 3NF”，就像在说“这辆卡车不符合赛车的空气动力学”——场景不对。

我在实际项目里见过一个反例：某个团队把数仓的宽表设计思路搬到业务库，把用户、订单、商品、支付全部打平到一张表，字段一百多个。上线两个月，数据对账就没平过，最后花了一个季度重构成范式结构。这个教训值得记一下：先确定这张表服务的是交易还是分析，再决定用哪套方法论。

7. 常见问题排查与设计自检清单

7.1 高频问题速查表

下面这张表是我这些年处理表设计问题时整理出来的，遇到具体症状可以对着查。

7.2 一份能直接用的建表自检清单

每次评审表结构，我都会按这几个问题过一遍，基本能拦下八成问题：

• 这张表用一句话描述，主语是什么？如果一句话说不清，说明混了多个实体。
• 每个字段问一句“它描述的是主键，还是描述另一个字段”？答案后者的，考虑搬走。
• 有没有字段的值里出现了分隔符（逗号、竖线、分号）？有就查一下是不是多值。
• 有没有xxx1、xxx2、xxx3这种带序号的列？有就考虑拆子表。
• 有没有 JSON 字段被用在where条件里？有就考虑提列。
• 主键是业务字段还是代理键？如果是业务字段，确认它永远不会变。
• 所有外键字段和常用查询字段，索引都建了吗？
• 涉及金额、价格、数量的字段，有没有区分“当前值”和“下单时快照”？

这套清单看着简单，但每一条背后都有真实的线上事故。尤其是最后一条，我在三个不同项目里见过同一个错误：订单表只存sku_id，展示时 join 商品表取价格，结果一做大促调价，客服电话就被打爆。

7.3 几个我踩过的坑

第一个坑是过度拆分导致事务变复杂。有个项目把用户信息拆成了user_base、user_profile、user_setting三张表，本来注册只需要插一条，变成插三条还得包事务，任何一张失败都要回滚。后来合并成一张表，字段多但不影响性能，维护成本降了一大截。拆表的前提是这些数据有不同的生命周期或访问频率，如果永远一起读写，拆开纯属自找麻烦。

第二个坑是把枚举值拆成独立表。理论上状态、类型这些枚举确实该有独立表维护，但如果只有三五个固定值、永远不变，拆表之后每次查询都多一次 join，收益为零。我的判断是：枚举值少于 10 个且业务上不会动态增加，直接用tinyint加注释，别建表。

第三个坑是忘了给外键建索引。这个最隐蔽，因为开发环境数据量小，怎么查都快，一上生产就原形毕露。我现在养成的习惯是，凡是xxx_id结尾的列，先问一句“这个字段会不会出现在 join 或 where 里”，会就立刻加索引，别等慢查询告警。

最后一个心得，关于怎么看待三范式这件事本身。我现在的做法是：设计阶段严格按 3NF 走一遍，然后针对具体的查询场景做有意识的、有记录的反范式决策。哪些字段冗余了、为什么冗余、由谁负责同步、怎么对账，全部写进设计文档。这样半年后接手的人看到冗余字段不会一脸懵，也不会有人为了“优化”把它删掉。范式是手段，不是目的，把数据的语义理清楚、把一致性维护成本降到可控，才是设计表这件事真正的目标。