影响读取的因素

　　堆表的结构特征会对数据读取效率产生很大的影响。前面在介绍堆表结构和聚簇因子时，已经详细说明了其中的一部分影响因素。接下来，我们还会说明需要了解和注意的其他几个影响因素。

　　大范围数据读取的处理方案。

　　提高聚簇因子的处理方案及重构表时的注意事项。

　　大范围数据读取的处理方案

　　在堆表中，由于数据是按照插入顺序被存储在磁盘的任意位置上，所以存储时所需要付出的代价相对较少。但是在读取满足特定查询条件（SQL语句中WHERE之后的条件）的数据时，所需要付出的代价则相对较大。当然，这并不是我们所能左右的事情。我们知道，当读取的数据量非常少时，不论怎么读取都能获得非常好的读取效率；但是当读取的是海量数据时，问题就从根本上发生变化了。

　　例如，当人体内的病菌数量非常少时，只需要通过打预防针，以增强免疫力，就能够治愈。但是，当人体内的病菌数量非常多时，以至到了威胁生命的程度，那就不再是仅仅通过注射预防的药物就能够治愈的问题了。再比如，假设读取1行数据需要花费0.01秒，那么读取10行数据也只不过是花费了0.1秒而已。但是如果需要读取1亿行数据，则所花费的时间为1 000 000秒，即277小时，将近12天。在查询数据时，等待0.1秒也许根本就觉察不到；但是如果要等待12天，则无论如何都是无法忍受的。

　　虽然这里举的这个例子有些极端但却是事实。在必须要处理海量数据的情况下，所采用的处理方案从根本上就应与面对少量数据时不同。因此，作为用户，我们首先应当认识到这一问题的严重性，绝不可以掉以轻心。很多用户认为，在处理海量数据时不应当使用堆表，事实并非如此，堆表在管理海量数据方面具有其他类型表无法比拟的优势。在堆表结构中，由于处理海量数据的各种解决方案（并行处理、分区、各种索引等）都可以使用，所以在现实中有很多用户都在使用堆表来存储海量数据。

　　即便在预测到将要处理的数据量会非常大的情况下，也仍然可以选择使用堆表来存储数据，这主要是因为这可以减轻数据插入时的负担。当然，如果插入数据时的负担并不是很大，则为了提高数据的读取效率，我们可以选择使用其他类型的表来存储数据。但是，在对数据存储速度要求非常高的情况下，相信没有哪个用户愿意为了给数据寻找一个好的存储位置而花费时间。

　　有些用户可能会把需要存储的数据暂时存储在临时位置上，等到闲暇时再将数据移动到磁盘的合适位置，但是这种方法并不像我们想象的那样容易。事实上，在大部分的RDBMS中，都是只在内存中对用户要求的数据进行处理，然后等到闲暇时再将处理结果从内存中移出并存储在磁盘的合适位置上。我们将此方式称为延迟写入（Deffered Write）。

　　在我们所开发的应用程序中，如果试图使用延迟写入的方法来处理数据，则由于每次都要通过编写代码来实现，使用起来会比较费劲。综上所述，在无法避免由于插入数据而造成的很大负担的情况下，不仅要对堆表予以充分的肯定，而且还要尽最大努力去寻找其他有效解决方案。在本书的后面会不断涉及此问题的不同解决方案，在此不进行过多说明。

　　在作者看来，堆表其实是最普遍的数据存储结构。乍一看，好像堆表只是在存储海量数据方面比较有效；但事实并非如此，也希望各位读者不要产生不必要的错觉。堆表所具有的唯一优点就是在数据插入时不需要采取任何特别的措施，只需顺其自然按照数据插入的顺序存储，因此减少了插入大量数据时的代价。仅此而已，再无其他任何优势可言。

　　依据表中所要存储数据量多少的不同，将表分为小型表、中型表、大型表。在这三种类型中，都会有一些对决定表结构产生一定影响的因素，在这里将予以详细说明。

　　小型表

　　首先来分析一下小型表的特征，所谓的小型表就是指表中所存储的数据量相对较少。这不仅意味着数据插入时的代价相对较小，而且还意味着数据被分散存储在较少的数据块上。假设把小型表中数据的存储区域视为一个个圆，则该圆的半径也会相对较小。例如小村子里的人们即使居住得比较分散，相对而言他们之间的距离其实也并不怎么远。然而，表的这些特征会对后来的数据读取有着非常大的影响。

　　在关系型数据库中，不论是何种类型的数据读取，每次最少都需要读取一个以上的数据块。由于小型表数据块数量相对较少，重复读取缓存在内存中的概率也相对较大，所以尽管是随机读也能获得非常好的数据读取效率。

　　如果小型表是在关键访问路径（Critical Access Path）上，则即使非常微小的差异也会由于频繁读取而被放大得非常明显。在此情况下，就有必要使用更加有效的方法（例如索引组织表，或者聚簇表）来存储数据。事实上，由于大部分小型表都不在关键访问路径上，所以除了特殊情况之外，一般没有必要采取额外的措施。