范式用于减少冗余、提高一致性，反范式用于提升性能；设计数据库时应优先使用范式，在性能瓶颈或查询复杂度过高时考虑反范式。一、范式能确保数据更新安全、结构清晰、
减少异常，如用户和订单信息分离；二、反范式适用于频繁多表关联、读多写少、分布式系统及简化复杂sql的场景；三、做反范式时需控制范围、保持一致性机制、记录设计原因；四、建议初期按范式设计，上线后根据监控优化，报表系统可建宽表，缓存也可替代冗余。
数据库设计时，范式是基础，但不是绝对。什么时候该用范式，什么时候又需要考虑反范式？ 简单来说：在保证数据一致性和结构清晰的前提下，当性能成为瓶颈、查询复杂度过高时，才考虑反范式设计。
下面从几个常见角度来看看具体怎么判断和操作。
范式（Normalization）是一种数据库设计方法，目的是减少冗余、提高数据一致性。常见的有第一范式（1NF）、第二范式（2NF）、第三范式（3NF），甚至BCNF等。
为什么要优先使用范式？
举个例子，用户表和订单表分开存储，用户信息变更只需改一次，而不是每个订单都改一遍。
反范式（Denormalization）是指有意引入冗余，以提升查询效率或简化结构。通常在以下几种场景中会考虑：
频繁的多表关联影响性能
比如订单详情页经常要查用户姓名、商品名称，每次都连几张表，慢。
读多写少的业务场景
如报表系统、日志分析平台，数据一旦写入很少改动，适合缓存冗余字段。
分布式系统中跨库查询困难
分库分表后，JOIN成本很高，提前把常用字段复制过来，能省很多麻烦。
为避免复杂SQL而优化结构
某些业务逻辑下，SQL语句太长、嵌套太多，通过冗余可以简化代码逻辑。
如果你决定使用反范式，有几个关键点需要注意：
举个简单的例子：
假设你有一个订单表，里面原本只有 user_id，现在为了展示方便加了 user_name 字段。
这时候就要注意：
实际开发中，范式为主、反式为辅是比较稳妥的做法。可以参考以下几个建议：
基本上就这些。
范式是基础，反范式是手段，关键是看业务场景和性能需求。