SQL数据建模面试重在权衡业务约束、查询效率与维护成本，而非死记范式定义；需结合冗余后果、更新异常识别问题，用ER图拆分表并说明外键关系，反范式须有明确场景、收益及同步机制。
SQL数据建模面试中，范式与反范式不是考死记硬背定义，而是看你能不能在业务约束、查询效率、维护成本之间做合理权衡。核心是理解“为什么这么设计”，而不是“该不该满足第三范式”。
范式考点：重点在识别冗余和更新异常
面试官常给一张未规范的表（比如订单表里重复出现客户姓名、地址、商品描述），让你指出问题并重构。关键不是说出“这是违反第二范式”，而是讲清后果：
- 同一客户信息在多行重复 → 存储浪费，且修改时可能只改了部分订单，导致数据不一致
- 订单和商品信息混在一起 → 某商品下架后，历史订单里的商品名可能被误删或无法关联
- 新增一个没下单的客户？无法插入（缺失订单号）→ 违反实体完整性
建议现场画ER图或写出拆分后的表结构（如customers、orders、order_items），并说明外键怎么连、主键怎么选。别只说“拆成三张表”，要讲清楚每张表存什么、谁引用谁、为什么这个粒度合适。
反范式考点：不是“错”，而是有明确理由的妥协
当面试官问“什么时候可以故意冗余字段”，别答“为了快”。要结合场景说具体收益和可控代价：
- 报表类系统查订单+客户城市+商品分类，频繁JOIN三张表拖慢响应 → 在orders表里冗余city和category_name，用触发器或应用层保证同步
- 高并发读写评论表，统计每个帖子的评论数总要COUNT(*) → 在posts表加comment_count字段，写评论时原子更新（UPDATE posts SET comment_count = comment_count + 1 WHERE id = ?）
- 用户头像URL在users和notifications里都存一份 → 避免推送通知时还要JOIN查头像，且头像变更频率低，同步成本小
一定要补一句：“冗余字段必须有明确的更新机制，不能靠人工维护。” 否则就是设计缺陷，不是反范式。
高频陷阱题：范式级别判断与边界案例
注意这些易错点：
- “订单时间”放在订单明细表里？ 看业务含义——如果明细行共享同一个下单时间，那它属于订单实体，应存在orders主表，明细表只存外键；若每条明细可独立设置生效时间（如分批发货时间），才属于明细自身属性
- JSON字段算不算反范式？ 不一定。存配置、扩展属性、非结构化日志时，用JSON是合理设计；但把能枚举的字段（如“订单状态”）塞进JSON，就丧失索引和约束能力，属于偷懒，不是反范式
- “满足第三范式就一定好？” 不。比如多语言内容：把中文、英文标题全放在products表里，看似无传递依赖，但字段数爆炸、空值多、新增语言要改表结构 → 正确做法是建product_translations表，哪怕引入JOIN
如何回答“你项目里怎么做的？”
选一个真实场景，用“问题→分析→方案→效果”四步说清：
- 问题：后台导出销售报表要JOIN 7 张表，平均耗时 12 秒
- 分析：其中 3 张表只用来取地区名称（省/市/区），且几乎不变更
- 方案：在事实表sales_records里冗余province_name、city_name，通过定时任务每天凌晨同步一次（因地区表极稳定）
- 效果：导出降到 1.8 秒，数据一致性有保障，运维成本增加可接受
不复杂但容易忽略。
