增删改查，除了增，其他三样都是和查有关，你搞的定select，那么update和delete的性能基本就没问题，今天我们专门讨论一下insert的性能提高。

很多DBA或程序员感觉一旦发出insert into，性能只能听天由命，似乎没有什么好的办法去解决，大家可以顺着以下思路去考虑关于insert的性能提升：

1、修改表的属性为Append ON。

DB2的表属性Append有开和关两种状态，默认情况下是关：

db2inst1@db2v105:~> db2 "select append_mode from syscat.tables where tabname = 'EVENTS'"
 
APPEND_MODE
-----------
N

 

  1 record(s) selected.

当表的数据被删除时，DB2的做法是空间并不会立即释放，而是在原数据上做删除标记，表示该行的空间可以重用，当在Append OFF发生insert时，DB2会扫描整个表的空闲空间，然后插入新行。修改Append为ON以后，DB2将不再搜索空闲空间，而是直接把数据插入到表的最后，由于少了检索的这一步，就可以提高效率，所以从根本上讲，默认情况下的insert隐含着会带有查询，这种特性适合于那些大批量追加数据的表，主要用于数据迁移场景，Append属性值为ON以后，需要注意经常reorg table。

db2inst1@db2v105:~> db2 create table t like syscat.events
DB20000I  The SQL command completed successfully.
db2inst1@db2v105:~> db2 alter table t append on
DB20000I  The SQL command completed successfully.
db2inst1@db2v105:~> db2 "select append_mode from syscat.tables where tabname = 'T'"
 
APPEND_MODE
-----------
Y         
 
  1 record(s) selected.
 
db2inst1@db2v105:~> db2 alter table t append off
DB20000I  The SQL command completed successfully.
db2inst1@db2v105:~> db2 "select append_mode from syscat.tables where tabname = 'T'"
 
APPEND_MODE
-----------
N         
 
  1 record(s) selected.

2、尽量使用DMS表空间。

万一不幸你用的是SMS，可以使用db2empfa工具，它能让SMS支持多页文件的空间分配（multi-page allocation），这将允许SMS 表空间一次增长一个Extend，而不是一页，从而可以加快那些大型的插入操作和溢出磁盘的排序操作。由于SMS几乎绝迹，这招insert加速大法可以忽略。

3、增加Log Buffer参数。

数据库的这个参数有时会被DBA视而不见，它用于指定日志记录在写入磁盘前的缓冲大小。注意：这个参数必须小于或等于dbheap参数，因为log buffer size是dbheap的一部分，这个冷知识了解到的人可能不多，因为dbheap通常都是automatic的。

db2inst1@db2v105:~> db2 get db cfg for zuma|grep -i logbufsz
 Log buffer size (4KB)                        (LOGBUFSZ) = 1602
db2inst1@db2v105:~> db2 get db cfg for zuma|grep -i dbheap
 Database heap (4KB)                         (DBHEAP) = AUTOMATIC(3300)

增加缓冲日志记录将导致更高效的日志文件I/O，这样可以让日志记录写入磁盘的频率更低，一次性写入更多的日志记录，但是很显然日志缓冲也不能太大，这其中的原理请大家再翻看一下我以前博客的内容吧。

4、避免网络开销。

只要有条件，你的insert发起就最好就发生在服务器端，或和服务器在同一个网络安全域中进行，例如有用ETL工具做数据迁移，其实质是insert into，此时ETL工具所在服务器都要避免要穿过三个路由器五个防火墙这种。

5、使用参数标记。

在insert语句中尽量使用参数标记，以及多行插入，这样可以避免SQL硬解析。

6、集中提交。

别一个insert就提交1次，数据库都让你这样给玩坏了，观察着点数据库快照，看下日志的空间占用情况，只要情况允许，就尽量10万提交一次，50万提交一次吧，这样一下性能就会厉害出很多。

db2inst1@db2v105:~> db2 get snapshot for database on zuma|grep space
Log space available to the database (Bytes)     = 102753583
Log space used by the database (Bytes)        = 1592017
Maximum secondary log space used (Bytes)     = 0
Maximum total log space used (Bytes)           = 2359011

用了JDBC的，更要成批提交，如果能用COMPOUND SQL那就尽量用。

7、检查一下和缓冲、IO有关的参数或设置。

比如NUM_IOSERVERS，NUM_IOCLEANERS，CHNGPGS_THRESH这三个参数，前两个的意义大家再查一下inforcenter，现在DB2版本都有automatic可用，CHNGPGS_THRESH以前我写过大篇幅的讨论，还有并行IO等，不再浪费唾沫。最最重要的是bufferpool，一定要足够大，足够合理才行。

8、检查关联的逻辑对象。

要insert的表是否有自增列、触发器、外键、检查约束等，这些都是影响性能的一些因素，如果有，能关的关能砍的砍，具体视情况而定吧。

9、解决服务器和存储故障。

我遇到过一次insert性能低下的case，上述8招都考虑或用过了，仍然不见效，于是细细的排查了服务器自身性能，光纤线接入，RAID条带等，最后发现存储只有一个控制器在工作，重启控制器后，那速度，刷刷的，这个让人很委屈的case感觉特别坑。