随着业务发展，单表的数据量已达实际应用推荐的极限，继续增加可能会性能瓶颈，考虑到后续业务发展，必须把现有数据按比例拆分到多张分表，这样变相地提高了单表容量。
分表性能关注：
分表索引数据的读取比较频繁，需要考虑使用缓存机制，以及定期更新缓存的机制，减少单表压力，提高性能。
批量操作时如果涉及到多个分表的读写，应该顺序执行，减少数据库的并发请求。同时业务系统应该关注批量查询的时间段，减少无意义的大范围查询功能。
分表测试方案设计：
压测场景 (单表铺底500w)
单条数据插入：A表
单条按主键查询，数据集中在同一张分表：A表
单条按主键查询，数据分散在不同分表：A表
单条按条件查询，数据集中在同一张分表：A表
单条按条件查询，数据分散在不同分表：A表
单条按主键修改：B表
单条按条件修改：B表
单条按主键删除：B表
批量数 据插入：C表 x1000
按条件查询列表，数据集中在同一张 分表：C表
按条件查询列表，数据分散在不同分 表：C表
按条件更新多条记录：C表
开启事务时，多次单条数据插入：A表
开启事务时，多次批量数据插入：D表
开启事务时，多次单条按主键修改： E表
过程中发现问题及优化方法：
统计信息
同样的表，同样的条件，同样的索引，为何出现如此不稳定的数据？
数据量增长了20%！！！
需要从新收集统计信息。
统计信息的重要性：
为了执行查询或 DML 语句（INSERT、UPDATE、DELETE），DB2 必须创建一个访问计划（access plan）。访问计划定义按什么顺序访问表，使用哪些索引，以及用何种连接（join）方法来关联数据。好的访问计划对于 SQL 语句的快速执行至关重要。DB2 优化器可以创建访问计划。这是一种基于成本的优化器，这意味着它是根据表和索引的相关统计信息来作出决策的。
收集统计信息-runstats
runstats on table [模式名].[表名] with distribution and detailed indexes all
注意：你可以在所有列上，或者仅仅在某些列或列组（除了LONG和LOB列）上执行RUNSTATS。如果没有指定特定列的子句，系统则会使用默认的ON ALL COLUMNS子句。
如果为单一索引进行runstats，可以使用： runstats on table [模式名].[表名] for indexes [索引名]
一个SQL在写完并运行之后，其实我们只是告诉了DB2去做什么，而不是如何去做。而，具体的如何去做，就取决于优化器。优化器为了生成最优的执行计划，就得掌握当前的系统信息，目录中的统计信息等等。 runstats命令就是用来收集数据库对象的状态信息，这对优化器生成最优的执行计划至关重要。
什么时候需要runstats？
1.给表创建一个index后，我们最好做一次runstat，否则可能index没有生效
2.对table做了一次reorg后，记得要做一次runstats
3.表里数据发生了比较大的变化，一般来说，大约表里面的数据量的10%-20%发生了变化，就应该作一次runstats
4.当你在分区(DPF)数据库里面使用了REDISTRIBUTE DATABASE PARTITION GROUP这个命令，那么就需要用runstats来收集新的统计信息
执行了runstats的效果。
执行前
执行后
如何优化执行计划：
1.适当的runstats和reorg
2.尽量使用索引条件
3.在sql中仅选择需要的列
4.调整where条件
在 DB2 优化器中使用分布统计信息的原文出处：http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0606fechner/