的优化和索引范式和非范式

Schema的优化和索引 - 范式和非范式4

然而，这样做会使更新account_type消耗更大。因为你需要更新两张表。要知道这是否是个问题，你必须要考虑的是这些更改的频率和多久会变化，在比较SELECT查询的频率。

把一些数据从父表移动到子表还有一个好处就是为了排序。举个例子，如果按照author名字来排序message的话，你可以把author_name在message表中缓存和索引，这样的查询语句是非常高效的。

这对于一些衍生数据的缓存也非常有用。如果你需要显示每个用户有多少条信息，你可以使用子查询来计算这些数据，也可以在user表中添加一个num_message字段，当user发布一个message的时候再更新它。

缓存和汇总表(Cache and Summary tables)

有的时候提升性能最好的方法就是在相同的表中存放冗余的数据。然而，有的时候，你可能需要创建单独的汇总或缓存表来优化查询。如果你能容忍少量过时的数据，这种方法是最佳的了，但是有的时候你真的没有选择。

关于缓存表和汇总表都是不标准的说法。如果我们提到缓存表就意味着表中包含的数据可以很容易的获取（数据是逻辑上的冗余）。当我们说道汇总表的时候，意思就是通过GROUP BY来聚合数据（数据不是逻辑上的冗余）。一些人也叫这些表为“roll-up tables”。因为数据是不断累积的。

就是遵循市场规律 继续回到上一个web站点的例子，假使你要计算24小时之前的message之和。在一个访问量很大的站，实时精确的值是不太可能的。我们可以每小时生成一个汇总表。这样完成这个需求只需要一个查询语句，并且这也比维护一个累加字段更高效。缺点就是这个数值并不是100%的精确。

如果你需要一个精确的数值，还有另一个选择。你可以把那个时间段中的23小时的的，开始时间段的部分小时的，还有时间段结束的部分小时的message数相加来得到准确的值。假使你的汇总表叫做msg_per_hr并且定义如下