DB2数据库更新数据缓慢，求优化建议

你这样写很不好，看起来写的是一句sql，反而速度慢下来了。首先row_number() over() as rownum毫无必要，这样来分页效率不高。然后能不用*就不用*查询。在大数据量和列很多的情况下，会慢很多。

而且你也说了，更新1W条数据需要半个小时。那么可以采用存储过程或者程序来访问。这样会快很多，推荐采用存储过程，110W条数据，就算重建索引等，更新一条应该在200ms一下，一万条，不会那么久的。希望能帮助得到你。

你这样写sql语句，执行时间太久了，会造成假死现象，这样很不好。

按照你的说法，是先从一个表（假定表名为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的所有认证，希望我的回答对你有所帮助。

---