在大学课堂上，老师教数据库设计时会敲着黑板强调：“一定要遵守第三范式（3NF），消除冗余，避免异常！”于是，很多刚入行的兄弟在设计数据库时，恨不得把一张表拆成八张，以此来展示自己扎实的理论功底。结果呢？上线第一天，一个关联查询（Join）把数据库 CPU 跑到了 100%，系统直接卡死。这时候你才会明白，架构设计没有“银弹”，只有“妥协”。今天咱们就聊聊软考高级架构师必须掌握的一个核心权衡：在数据库设计中，何时该死守范式，何时又该果断地“反范式”。一、 范式（Normalization）：学术界的洁癖为了照顾部分考友，咱们先快速复习一下范式。这玩意儿在软考上午的选择题里经常出现，属于送分题。第一范式（1NF）：属性不可再分。比如“地址”字段不能存“北京市海淀区”，得拆成“省”、“市”、“区”。第二范式（2NF）：消灭部分函数依赖。简单说，就是非主键字段必须完全依赖于主键，不能只依赖主键的一部分（主要针对联合主键）。第三范式（3NF）：消灭传递依赖。A 决定 B，B 决定 C，那 C 就不应该直接放在 A 的表里。范式的好处是显而易见的：数据不重复，空间利用率高，插入、更新、删除异常少，数据一致性好维护。