DB2ADMIN XIE4T_CKD   4893     6     2    18      6   90   80   18   ---

SYSIBM   SQL010510174815750   4893    49     2    28   4893   81   87    2 ---

--------------------------------------------------------------------------------

CLUSTERRATIO 或正常化的 CLUSTERFACTOR (F4) 将指示索引需要

REORG，该索引与基表不在相同的序列中。

当在表中定义了多个索引时，一个或多个索引可能被标记为需要 REORG。  指定 REORG

顺序的最重要索引。

至此，试验完成。接下来比较一下运行统计和重组前后运行成本，如下图：

运行重组统计前

运行重组统计后

对比运行统计前后的SQL语句成本可以看出由运行前的4469变成了运行后的1572，运行成本是原来的三分之一多。然后再运行程序发现响应速度比以前有大幅度的提高，到此这个棘手的问题算是解决了（当然这是治标不治本，要从根本改变就应该从SQL语句本身入手优化它的性能）。同时我对于“采用导入的方法将此表数据装载进来却没有发现上述现象”这个问题也找到了答案，那就是——在IMPORT过程中由于导入目标表示新表，IMPORT工具将会用类似运行统计的方式将数据均匀填充到叶面当中，因此速度也会加快。这个问题说明对于在数据库中那些经常发生变动的表，定期进行运行统计是对数据库性能提高是有帮助的。

【附录：一些其他的背景知识】

对 reorgchk 所使用的度量的考虑因素包括：（当查看 reorgchk 工具的输出时，找到用于表的 F1、F2 和 F3 这几列，以及用于索引的 F4、F5、F6、F7 和 F8 这几列。如果这些列中的任何一列有星号 (*)，则说明当前的表和/或索引超出了阈值。）

F1: 属于溢出记录的行所占的百分比。当这个百分比大于 5% 时，在输出的 F1 列中将有一个星号 (*)。

F2: 数据页中使用了的空间所占的百分比。当这个百分比小于 70% 时，在输出的 F2 列上将有一个星号 (*)。

F3: 其中含有包含某些记录的数据的页所占的百分比。当这个百分比小于 80% 时，在输出的 F3 列上将有一个星号 (*)。

F4: 群集率，即表中与索引具有相同顺序的行所占的百分比。当这个百分比小于 80% 时，那么在输出的 F4 列上将有一个星号 (*)。

F5: 在每个索引页上用于索引键的空间所占的百分比。当这个百分比小于 50% 时，在输出的 F5 列上将有一个星号 (*)。

F6: 可以存储在每个索引级的键的数目。当这个数字小于 100 时，在输出的 F6 列上将有一个星号 (*)。

F7: 在一个页中被标记为 deleted 的记录 ID（键）所占的百分比。当这个百分比大于 20% 时，在输出的 F7 列上将有一个星号 (*)。

F8: 索引中空叶子页所占的百分比。当这个百分比大于 20% 时，在输出的 F8 列上将有一个星号 (*)。

对所有表运行 reorgchk 工具，并确保您正在使用当前统计信息，可使用命令：

reorgchk update statistics on table user

可以使用如下语句来检查任何没有统计信息的表：

select tabname from syscat.tables where stats_time is null

可以使用如下语句来检查任何没有统计信息的索引：

select indname from syscat.indexes where stats_time is null

可以使用如下语句来查找具有时间超过 30 天的统计信息的表和索引：

select tabname from syscat.tables
        where stats_time < current timestamp - 30 days
select indname from syscat.indexes
        where stats_time < current timestamp - 30 days

注意： 在使用 runstats 命令的时候，必须指定表所在的模式。