db2数据库表数据量太大如何横向拆分

对于表的数据量在百万上的使用delete from table_name 时候，会很慢很慢，难以接受。而且delete删除多张表数据时更难以接受。找了下方法，发现非常的快。步骤如下：

>

reorgchk，检查table index 是否需要重组。reorg 重组，重新放置数据位置。runstats 统计信息，可以优化查询器

一个完整的日常维护规范可以帮助 DBA 理顺每天需要的 *** 作，以便更好的监控和维护数据库，保证数据库的正常、安全、高效运行，防止一些错误重复发生。

由于DB2使用CBO作为数据库的优化器，数据库对象的状态信息对数据库使用合理的 ACCESS PLAN至关重要。DB2 优化器使用目录统计信息来确定任何给定查询的最佳访问方案。如果有关表或索引的统计信息已过时或者不完整，则会导致优化器选择不是最佳的方案，并且会降低 执行查询的速度。当数据库里某个表中的记录变化量很大时，需要在表上做REORG *** 作来优化数据库性能

按照你的说法，是先从一个表（假定表名为A）里读取1000行数据，然后到正式表（假定表名为B）里分别判断每条记录，如果没有这条记录就INSERT到正式表，如果正式表有这条记录就UPDATE正式表的数据，然后再处理下一个1000行。我这个理解正确吗

如果是这样的话，从A表取数据的WHERE条件中的谓词应该建成一个复合索引，并且排序字段建成一个单独的索引（rownumber() over(order by 排序字段 asc ) as rowid)，这样能很大程度上加快读的速度，这个语句频繁执行，是优化的关键点。

接下来判断每条记录在B表是否存在，这个WHERE条件中的谓词也应该建成一个复合索引，因为这个语句会频繁执行，也是优化的关键点。

然后是判断，不知道你用的是什么语言来实现，这个地方已经跟数据库没有关系了，无法优化。

接下来是插入，如果能批量 *** 作，就考虑批量，比如JDBC的接口中addBatch()等方法，同时给B表添加append on特性，可以很大程度的加快插入速度，是优化的关键点。使用append 特性以后，请注意定期reorg table，alter table TAB_NAME append on。

接下来是更新，同样是做成批量 *** 作，这个UPDATE的WHERE条件中的谓词也建成一个复合索引，这个语句频繁执行，也是优化的关键点。

然后数据库层面：

日志缓冲池(LOGBUFSZ)调整成8192个页面，可以减少日志I/O，这个也是优化的关键点；

活动日志、归档日志所在的磁盘与数据所在的磁盘要分开，因为I/O是数据库最耗时的 *** 作，瓶颈一般都处在这个地方，这个也是优化的关键点；

数据和索引及大字段分开存放在不同的表空间，数据和索引不要用文件缓存，大字段启用文件缓存；

索引使用的缓冲池最好保证索引完全能够容纳进去，这样能很大的加快查询速度，这也是优化的关键点；

日志文件大小最好定义为100MB，主日志大小定义为10，辅助日志大小定义为20，即LOGFILSIZ=25600，LOGPRIMARY=10，LOGSECOND=20，这样可以减少日志频繁归档和保证一个事务可以进行更多的DML *** 作；

每次 *** 作不要只对1000行记录进行 *** 作就提交，因为频繁提交很耗时，建议调整为每次2W条，上面所说的日志配置应该足够确保不会出现日志空间满的问题。

我在银行的批处理 *** 作中做过12个参数表的这种临时表、正式表、查询、判断、INSERT、UPDATE的 *** 作，总数据量有14W条记录， *** 作时间都是在10分钟以内结束，而且是一台服务器上三个环境都有这样的作业在同时执行（即访问临时表和正式表中不同的记录）。

按照这个估算，你的280W条记录，应该可以在200分钟内结束。

我程序中用到的是JAVA、MYBATIS、SPRING的手动事务。

附：我拥有DB2 V9的所有认证，希望我的回答对你有所帮助。

以上就是关于db2数据库表数据量太大如何横向拆分全部的内容，包括:db2数据库表数据量太大如何横向拆分、如何使用 REORG 和 RUNSTATS 命令优化数据库性能、“db2 reorg” 做什么用的等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！