大型表

　　最后让我们再来考虑一下大型表。对大型表的分类方法有很多，在这里我们将其分为以下三类。

　　第一类：单纯的存储型表。在这里以管理日志信息的表为例来进行说明，这样的表既不会被经常使用，也不会有多样化的读取要求。只有在特殊的情况下，才有可能要求按照特定的读取类型读取数据，或对大量的数据进行扫描，并且日志表还要求具有较快的存储速度。综合这些特征和要求，使用堆表来存储此类数据是最佳的选择。另外，由于数据增长的速度会比较快，所以最好能够为其创建分区。

　　第二类：像顾客表这样虽然存储着大量的数据，但主要是以随机读取为主，并不存在多样化的读取类型的表。这种情况下，堆表仍然是比较适合的选择。一次性向这样的表中插入大量数据的情况非常少见，范围处理（要求处理的数据范围相对比较大）的情况也不会经常出现。

　　尽管按照某个列对表进行了分区，但是经常会出现并不是只读取某个特定分区的情况，而且为了某个特定部分而对其进行单独操作的机会也并不多，所以即使创建了分区表或聚簇表，也不会获得太大的效益。

　　第三类：像销售表这样的表不仅数据急速大量增加，而且具有多样化的数据读取类型。一般情况下，拥有这种特征的表对系统会产生极大的影响。不论从数据管理的角度还是从数据读取的角度来看，都具有非常大的负担。如果我们没有为这种类型的表制定出合理的解决方案，那么各种问题就会接踵而至。

　　如果急速增加的数据对管理造成了很大的负担，则应当当机立断为其创建分区。关于如何更好地使用分区的相关内容将在后面予以详细说明。由于经常需要对这种类型的表执行大范围数据扫描，所以如果再扫描了大量本不应该扫描的数据，则会导致非常严重的后果。

　　我们为如何只对所需要的数据进行读取的问题提供了多种有效的解决方案。其中构建有效的索引和确保最优化的SQL执行计划是其中最为重要的两个方法。除了这些解决方案之外，我们优先应该解决的问题就是，如何决定只能按照一种顺序存储数据的表结构。

　　不论是调整索引结构、修改SQL语句，还是改变执行计划，相对而言都比较容易，但改变表的结构却不是一件容易的事情。