简谈DB2的性能问题诊断（三）

        这节，简单总结一下语句的优化吧。

        前面，我们提到了，当应用有性能问题时，系统资源使用率一般比较高。这个时候，使用db2 get snapshot for applications on <dbname>可以抓到处于UOW Executing状态的应用，然后，可以从应用的快照中看到SQL语句。

        当我们确定这些语句确实需要优化的时候，我一般的步骤是这样的（不一定最好，供参考）。

        1. 首先看这条语句的执行计划是不是明显不合理，比如说明显没有使用合适的索引，或者有明显有可以是语句性能提高的索引。

           db2expln -d <dbname> -t -g -q "<SQL Statement>"

        2. 看一下统计信息是否up to date。

           db2 "select stats_time, card from syscat.tables where tabname='<tabname>'"

          如果统计信息明显不及时，更新统计信息（表如果太大，就抽样更新）。

          db2 "runstats on table <tabschema>.<tabname> with distribution and detailed indexes all"

        3. 问题如果还没有解决，再次查看统计信息。找到开销最大的阶段。分析如何优化。

        4. 如果语句太复杂，不能轻易的分析出最好的索引，运行db2advis看一下优化器的建议：

           db2advis -d <dbname> [-s <statement> -f <file contain the SQL>]

           如果优化器给出来的语句能提高90%以上，那就别犹豫了，索引一定能解决这个性能问题。通常，建议出来的需要创建的索引是比较好的，但是有时候，我们可以分析一下这些索引，从而发现更好的索引。

        5. 到第4步，问题应该就能解决了。你可能在想，怎么没有reorg呢？我一般觉得表中的数据分布一般不会差到对性能影响太大，而reorg本身几乎让表处于不可访问状态。所以，我很少在业务在线的时候使用reorg。如果过了第四步，问题还没有解决，那麻烦了，这个时候可就得想各种各样的办法去优化了。

        a) 语句改写能不能提高性能，如将or改成union all

        b) 语句中的查询条件有没有函数，这些函数是不是可以取消

        c) 能不能通过增加或者修改查询条件减少结果集

        d) 我等着大家的评论....................

        上面是在线的优化步骤，离线的优化方式就很灵活了，比如说分区表、MDC、生成列、reorg......