数据库-三范式优化与不推荐使用外键

反三范式其实是基于三范式所调整的，没有冗余的数据库未必是最好的数据库，完全按照第三范式做表的设计可能会降低查询效率（涉及多表查询，多表连接JOIN，临时表创建GROUP BY），有时候为了提高运行效率，就必须降低范式的标准，适量保留冗余数据。

什么是三范式

• 第一范式：“第一范式的数据表必须是二维数据表”，第一范式是指数据库的每一列都是不可分割的基本数据项，强调列的原子性，某一属性不能拥有几个值。比如数据库的电话号码属性里面不可以有固定电话和移动电话值。 说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

• 第二范式：建立在第一范式的基础上，即满足第二范式一定满足第一范式，第二范式要求数据表每一个实例或者行必须被唯一标识。除满足第一范式外还有两个条件，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。

• 第三范式：满足第二范式，且每一个非主属性都不传递依赖于该范式的候选键，则称为第三范式，即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

三范式优化

• 主要是满足第三范式，即不产生数据冗余、插入异常、删除异常、依赖传递等。

拆分表，一张有依赖传递的表，如（blog、blog_class、blog_class_description）,拆分成 blog（主表）、blog_class+blog_class_description(依赖关系表)、blog+blog_class(关联关系表)

反三范式优化

• 反三范式其实是基于三范式所调整的，没有冗余的数据库未必是最好的数据库，完全按照第三范式做表的设计可能会降低查询效率（涉及多表查询，多表连接JOIN，临时表创建GROUP BY），有时候为了提高运行效率，就必须降低范式的标准，适量保留冗余数据。

• 在概念数据模型设计时遵守第三范式，降低范式标准的工作放在物理数据模型时考虑。
• 适当的合并一些表的字段（减少表的数量），产生一些字段冗余，降低了查询时的关联，有时候可以提高查询效率。
• 因为在数据库操作中，DQL的比例是要远大于DML的
• 反三范式优化一定要适度，并且是在原本满足但三范式的基础上做调整的。

为什么不推荐使用外键

外键的优点

数据一致性

由数据库自身保证数据一致性、完整性会更可靠。

ER图可靠性、可读性

有主外键的数据库可以增加数据库可读性

外键的缺点

级联

在阿里巴巴开发手册中，就强制要求不允许使用外键，所有的外键概念必须在应用层解决，因为每次级联DML操作时，都要级联操作相关的外键表，在高并发场景会导致性能瓶颈。

数据库压力增加

外键等于将数据库一致性实现，全部交给数据库服务器完成，有了外键，当进行DML操作后，需要出发相关的操作去检查，应用程序执行的判断转移到了数据库上，增加资源消耗，数据库性能开销变大。

死锁

每次修改都要去另外的表检查数据，获取额外的锁。高并发大流量事务场景，使用外键可能容易造成死锁。

开发、维护不方便

有外键在需要手工维护数据时，都需要考虑级联问题，数据库平台迁移（如Mysql迁移到DB2）和分库分表时，会省去很多麻烦