DB2数据库和ORACLE数据库一样，DB2数据库里面也是通过优化器来分析你的SQL，生成它认为***的执行计划(Access Plan)。DB2的优化器实际上是一个标准规则集合，一般来说我们只要告诉DB2要检索什么，而不是如何检索。
那么DB2的优化器是根据什么来判断SQL的***存取路径呢?
DB2的优化器是基于成本的优化器，也就是CBO(Cost Based Optmizer)。也就是说DB2 优化器会应用查询成本公式，该公式对每条可能的存取路径的四个因素进行评估和权衡:CPU 成本、I/O 成本、DB2 系统目录中的统计信息和实际的 SQL 语句。
那么我们来简单看一下DB2的优化器的工作流程:
1. DB2的优化器，在接收到SQL语句后，会首先校验SQL的语法，确保是正确的SQL
2. 根据当前的系统环境信息，生成***的执行计划来优化SQL语句
3. 把SQL翻译成计算机指令语言，并执行这个优化后的SQL
4. 返回结果，或者存储它们，以便将来的执行
在我们看来，DB2 系统目录中统计信息是让DB2优化器正确工作的一个非常重要的依据。这些统计信息向优化器提供了与正在被优化的 SQL 语句将要访问的表状态相关的信息。这些信息主要包括:
Table--包括表的记录数、PAGE、PCTFREE以及COMPRESS等信息，相关的系统视图是:sysstat.tables、syscat.tables
Columns—包括COLUMNS的数量、长度、分布特征以及COMPRESS等信息,相关的系统视图是:sysstat.columns、syscat. columns
Index--包括是否存在索引、索引的组织(叶子页的数量和级别的数量)、索引键的离散值的数量以及是否群集索引, 相关的系统视图是:sysstat.indexes、syscat. indexes
其他的还有分区/节点组信息和表空间的信息
如何及时更新这些信息呢?保证DB2优化器正确的工作，在DB2里面提供了以下的办法。
RUNSTATS与REOGCHK
Runstats这个命令的功能主要就是收集数据库对象的状态信息，这对数据库使用合理的ACCESS PLAN是至关重要的。一般来说，以下几种情况下面，我们需要用runstats来收集统计信息:
1. 在给表创建一个index后，我们***做一次runstat。这个情况也是大家经常忽略的。很多时候大家在给表增加了一个index后，分析执行计划，发现没有变化，觉得很奇怪。其实这个时候，你需要做一次runstats，就可以了。在8.2里面，DB2做了很好的改进，可以避免这个问题，在创建index的时候，可以立即更新你的信息。
2. 在对table做了一次reorg后，记得要做一次runstats。因为对表做reorg，会修改表的很多信息，比如高水位等，所以做一次runstats,可以更新统计信息。
3. 当你的表里面的数据发生了比较大的变化，一般来说，大约表里面的数据量的10%-20%发生了变化，就应该作一次runstats。这些变化包括删除，修改，插入。对于一些非常大的表，比方在数据仓库的项目里面，某些事实表非常巨大。这个时候，完整的对一个大表作runstats可能花费时间相当大，DB2 8.1里面支持我们对这些大表作抽样，比方说只对20%的数据作runstats，这样的话，一般来说也能保证得到正确的执行计划。当然首先要确保这个表里面的数据***分布比较均匀。
大家通过上文的学习有什么收获吗？相信大家现在对DB2中更新执行计划的操作有了大体的了解，以后在工作中遇到类似问题就能够轻松解决，希望上文中涉及到的内容对大家能够有所帮助。
