MySQL 深入浅出系列02—范式和反范式

范式和反范式

在范式化的数据库中，每个事实数据会出现并且只出现 一次。相反，在反范式化的数据库中，信息是冗余的， 可能会存储在多个地方。
第一范式（无重复的列），数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。通俗讲就是：一个字段只存储一项信息。
第二范式（属性完全依赖于主键），满足第一范式前提，当一个主键由多个属性共同组成时，才会发生不符合第二范式的情况。比如有两个属性的主键，不能存在这样的属性，它只依赖于主键中的一个属性，这就是不符合第二范式 。通俗讲就是：任意一个字段只依赖表中的同一个字段。
第三范式（属性不能传递依赖于主属性），满足第二范式前提，如果某一属性依赖于其他非主键属性，而其他非主键属性又依赖于主键，那么这个属性就是间接依赖于主键，这被称作传递依赖于主属性。通俗讲就是：一张表最多只存 2 层同类型信息

范式的优点和缺点

当为性能问题而寻求帮助时，经常会被建议对 schema 进行范式化设计，尤其是写密集的场景。因为下面这些原因，范式化通常能够带来好处：

• 范式化的更新操作通常比反范式化要快。
• 当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据。
• 范式化的表通常更小，可以更好地放在内存里，所以执行操作会更快。
• 很少有多余的数据意味着检索列表数据时更少需要 DISTINCT 或者 GROUP BY 语句。
  范式化设计的 schema 的缺点是通常需要关联。稍微复杂一些的查询语向在符合范式的 schema 上都可能需要至少一次关联，也许更多。这不但代价昂贵，也可能使 一些索引策略无效。例如，范式化可能将列存放在不同的表中，而这些列如果在一个表中本可以属于同一个索引。

反范式的优点和缺点

反范式化的 schema 因为所有数据都在一张表中，可以很好地避免关联。如果不需要关联表，则对大部分查询最差的情况—即使表没有使用索引—是全表扫描。当数据比内存大时这可能比关联要快得多，因为这样避免了随机 I/O。单独的表也能使用更有效的索引策略。

混用范式化和反范式化

最常见的反范式化数据的方法是复制或者缓存，在不同的表中存储相同的特定列。在 MySQL 5.0 和更新版本中，可以使用触发器更新缓存值，这使得实现这样的方案变得更简单。另一个从父表冗余一些数据到子表的理由是排序的需要。例如，在范式化的 schema 里通过作者的名字对消,息做排序的代价将会非常高，但是如果在message 表中缓存 author_ name 字段并且建好索引，则可以非常高效地完成排序。缓存衍生值也是有用的。如果需要显示每个用户发了多少消息(像很多论坛做的)，可以每次执行一个昂贵的子查询来计算并显示它；也可以在 user 表中建一个num_messages 列，每当用户发新消息时更新这个值。