数据散布
Data Dispersion

当条件是“非唯一性”的，或者条件以唯一性索引上的范围来表达时，DBMS 就必须执行范围扫描。例如：
where customer_id between . .. and ...
或：
where supplier_name like 'SOMENAME%'
键对应的记录很可能散布在整个表中，而基于成本的优化器知道这一点。所以，索引范围扫描会使 DBMS 核心逐一读取表的存储页，此时，优化器会决定 DBMS 核心忽略索引对表进行扫描。
如第5章所述，许多数据库系统提供了诸如分区（partition）和聚集索引（clustered index）等功能，直接将可能一并读取的数据存储在一起。其实，数据插入处理也常造成数据丛聚（clumping）保存的现象：如果每条记录插入表时都要加时间戳（timestamp），则相继插入的记录会彼此紧邻（除非我们采取特殊手段避免资源竞争，见第9章的讨论）。这其实没有必要，而且关系理论中也没有“顺序”的概念，但在实际中却很可能发生。

因此，当我们在时间戳字段的索引上执行范围扫描、查询时间上接近的索引项时，这些记录可能彼此紧邻——如果特意为此设置了存储选项参数，就更是如此了。
现在做一个假定：键值与特定插入环境无关、与存储设置无关，与键值（或键值范围）对应的记录可能存储在磁盘的任何位置。索引仅以特定顺序来存储键值，而对应的记录随机散落在表中。此时，若既不分区、也不采用聚集索引，则需访问的存储区会更多。于是，可能出现下列情况：同一个表上有两个可选择性完全相同的索引，但一个索引性能好、一个索引性能差。这种情况在第3章已提到过，下面来分析一下。
为了说明上述情况，先创建一个具有 1 000 000条记录的表，这个表有 c1、c2和 c3 三个字段，c1 保存序号（1 到 1 000 000），c2 保存从 1 到 2 000 000 不等的随机数，c3 保存可重复、且经常重复的随机值。表面看来，c1 和 c2 都具唯一性，因此具有完全相同的可选择性。索引建在c1上，则表中字段的顺序，与索引中的顺序相符——当然，实际上，对表的删除操作会留下“空洞”，随后又有新的插入记录填入，所以记录顺序会被打乱。相比之下，索引建在c2上，则表中记录顺序与索引中的顺序无关。

下面读取c3 ，使用如下范围条件：
where column_name between some_value and some_value + 10
如图6-1所示，使用c1索引（有序索引，索引中键的顺序与表中记录顺序相同）和c2索引（随机索引）的性能差异很大。别忘了造成这种差异的原因：为了读取c3的值，除了访问索引，还要访问表。如果我们有两个复合索引，分别在 (c1, c3) 和 (c2, c3) 上，就不会有上述差异了，因为这时不必访问表，从索引中即可获得要返回的内容。
图6-1说明的这种性能差异，也解释了下述情况的原因：有时性能会随时间而降低，尤其是在新系统刚投入生产环境并导入旧系统的大量数据时。最初加载的数据的物理排序，可能是有利于特定查询的；但随后几个月的各种活动破坏了这种顺序，于是性能“神秘”降低 30%～40%。


图6-1：“索引项顺序与表中记录顺序是否一致”对性能的影响

现在很清楚了，“DBA可以随时重新组织数据库”其实是错误的。数据库的重新组织曾一度流行；但不断增加的数据量及99 999 9% 正常运行等要求，使得重新组织数据库变得不再适合。如果物理存储方式很重要，则应考虑第5章讨论过的“自组织结构（self-organizing structure）”之一，例如聚集索引（clustered indexe）或索引组织表（index-organized table）。但要记住，对某种类型的查询有利，可能对另一种类型的查询不利，鱼与熊掌不可得兼。
总结：类似的索引，性能却不同，这可能是物理数据的散布引起的。