经常的执行"RUNSTATS"命令，用来更新DB2的目录统计，这样可以在特别繁忙的生产环境里中得到全貌。为了使执行"RUNSTATS"命令的影响最小化，可以考虑使用采样技术。即使取样10%也够了。另外"RUNSTATS"命令可以更新统计，DB2给您可以额外更新1,000个条目的能力，以用于不均匀的分类统计。当心随着每一条目随着增量的增加，而涉及到对所有参考的绑定时间的影响。
假如当您缺少统计的时候您怎么知道呢?当目录或使用工具不能提供这种功能的时候，您可以通过手工执行查询。当前,DB2优化器不能给缺失的统计提供具体的警告。
技巧2:尽可能的采用阶段1和阶段2的谓词:
不论是阶段1的数据管理器还是阶段2的关系型数据服务器都将处理每一次查询。当您处理查询时，使用阶段1将会比使用阶段2有着巨大的性能优势。当谓词确定阶段1能够处理的时候，通常谓词会限制您只能使用阶段1查询。另外,每一个谓词都会被检验评估是否比另一个谓词更有资袼作为索引路径。有一些谓词不能作为阶段1来处理，或是不符合索引的条件。关于您的查询是否可以被索引并且能够在阶段1被处理，理解这一点是很重要的。下面是文挡化的阶段1或Sargable(search+argument-able谓词是一个可以由数据管理器来值的谓词)谓词：
图3：通常用表单来确定谓词是否合格
还有一些谓词不能看作阶段1被文档化，因为他们不能总处于阶段1。加入表序列和查询重写也能够影响谓词被过滤掉的阶段。让我们通过例子查询来显示重写您的SQL的影响。
例子1:COL1和COL1之间的值:
任何类型的谓词如不能被阶段1识别，就是阶段2。如下所示就是阶段2谓词。然而,重写可能促进对可索引阶段1的查询:Value>=COL1ANDvalue<=COL2。
这意味着,优化器也许会在多个索引中选择一个匹配的索引来使用谓词。没有重写,谓词的剩余被当作阶段2。
例子2:COL3NOTIN(K,S,T)：
如果可能，非可索引的阶段1的谓词也应该被重写。例如，符合以上条件的是阶段1，但不是可索引的。括号里值的列表辨认什么与COL3不相等。为了确定重写的可行性，辨认出那些COL3不相等的、更长和更不稳定的表单，就越不具有可行性。如果对面的(K,S,T)是少于200的静态值,就值得输入额外的重写。促进阶段1的条件对于可索引的阶段1，提供了其它匹配索引选择的优化器。既使一个可支持的索引在绑定时间不可利用,重写也将确保查询具有索引访问的资格，并且此索引将在以后被创建。一旦一个索引被创建并与COL3合并,重新绑定的事务也许可能获得匹配的索引访问,那里的旧谓词将不会对重新绑定有影响。
