最近发现KETTLE抽数越来越慢，特别是增量INSERT/UPDATE的时候，速度已经达到了令人发指的地步（从一个400W数据规模的表中每天增量量抽取30W数据的TRASFORMATION 竟然要20个小时！！！！读取速率是5条/s......），这个情况是在我的KETTLE工具从3.2升级到7.0版本后发现的，（以前也慢，只是还能接受，升级之后已经到了不改不行的地步了），但是KETTLE是进步的，所以原因还是要从自身找起。
目前为止我发现的导致KETTLE抽取数据慢有以下几个原因：
A：SPOON 启动时候内存较小，在spoon.bat这个启动文件中，配置的有JVM的内存XMX,("%PENTAHO_DI_JAVA_OPTIONS%"=="" set PENTAHO_DI_JAVA_OPTIONS="- Xms8192m" "-Xmx8192m" "-XX:MaxPermSize=4096m"),默认这个是256M，512M 256M， 其中Xms是指JVM初始分配的堆栈的内存，Xmx是指JVM分配的堆栈的内存 （JAVA代码能涉及到的存储数据变量的内存）最大是多少，所以XMS必须要<= XMX,XX:MaxPermSize,是指JVM给自己分配的非堆栈内存（供虚拟机程序自己开销）我的因 为是在服务器上跑，因此改成了8192M8192M4096M,这个改不能是无限的加大，需要考虑总的内存大小，一般来说网上参考是最大堆栈内存不超过总内存的3/8有的也说是 一半，总之得有个度。
B：抽数的源数据库关键字段没有索引，以我这张表为例，我每天需要按照日期（data_update_date）从DB2增量抽取更新数据,但是这个字段没有建索引，因此也会导致抽数慢。
C：抽数的源数据库关键字段索引在SPOON里面失效，给大家看两段SQL就知道了：
SQL1:select TO_CHAR(TO_DATE(t_date,'YYYYMMDD')+1,'YYYYMMDD') from delta_table where t_name='~~~'
SELECT * FROM SAPCP1.ZCSSDH053 WHERE REPORT_CREATE_DATE >= ?
SQL2:select t_date from delta_table where t_name='~~~'
SELECT * FROM SAPCP1.ZCSSDH053 WHERE REPORT_CREATE_DATE > ?
两段SQL执行的都是相同的数据提取过程，但是在REPORT_CREATE_DATE 字段建立索引的情况下，SQL1比SQL2快20倍。原因是用 > 号的时候，索引会失效，而用>=则不会。
于是我在网上搜索了这种明明应该走 但是并没有走索引的情况（以下是粘贴的）
使用<> （有的时候单独的使用< 或者>的时候也有可能）
like的时候不能确定最前面的字符 也就是把’％_’的时候
单独使用复合索引的非前导列
表没有分析
字符类型不匹配 发生了显示的或者隐式的转换或者对索引列进行了运算
使用了 not in 或者 not exist
基于cbo时全表扫描代价小
b-tree索引is not null的时候会走，is not null的时候不会走 位图的时候都会 复合索引的时候 is not null会 is null时要看前导列
D：目的地数据库表的索引太多，这个原因显而易见，因为插入数据的时候会重新更新索引表，索引太多，插入时候会变慢。
E：插入流程中数据COMMIT过程太频繁，数据插入的COMMIT太频繁也是很影响效率的，
F：INSERT/UPDATE 过程与 表输入，这两个流程肯定是后者快很多，但是笔者在实际过程中会遇到一个问题就是，万一ETL抽数流程的某个环节发生了错误，导致ETL后面的流程DUMP掉，要么没插入要么部分插入，这样的话，肯定是没有更新关键字段的。（关键字段更新是放在所有流程最后一步），这样的话，当笔者解决掉这个问题重新启动流程，如果重头开始，对于INSERT/UPDATE字段没什么问题，数据重复会进行更新，但是对于表输入的话，就会有问题，昨天写入的数据已经存在了，这样不作处理肯定还会报错。KETTLE 7.0 解决了这个问题，在JOB层设计的时候提前设定好失败数据回滚的操作，在回滚的操作里面删掉已经插入的数据，这样的话用表输入就没有后顾之忧了。
最后，30W数据进过以上优化时间从20个小时缩短到0.5个小时~~我暂时发现这些优化方式，各位高人有其他方法欢迎交流~~~！！！！