大量数据

金蝶BOS里系统表 t_bas_message 表用于存放系统消息．实际操作中，客户端默认15分钟查询一次是否有新消息 用户基本不会去删除已读的消息，这就导致这张表大得惊人,系统运行一年多以来,大约有 4500万条数据．再加上这张表上存在索引，对数据库而言，一旦操作失误导致表中索引失效，数据库会因为全表扫描太多彻底卡死． 之后考滤删除一个月以前的数据执行SQL语句如下 DELETE FROM t_bas_message t WHERE t.fsendtime > Sysdate-30; 这段代码在测试库运行了两个多小时.一方面是数据量很大,另一方面是因为表中有几列索引.实际中这种方案肯定不行. 跟DBA讨论了一下,有两种方案. A 通过表分区操作. 通过表进行分区,然后直接删除无关分区.代码如下 -- 创建中间表,添加主键,索引,分区等信息 create table T_BAS_MESSAGE_bak ( fid VARCHAR2(44) not null ) partition by range (fsendtime) ( partition PART_20141201 values less than (TIMESTAMP' 2014-12-01 00:00:00'), partition PART_MAX values less than (MAXVALUE) ); -

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space 今天我想说说这个有趣的问题，这的确是个让人费解的是error 问题来源： 这个问题一般会出在myecplise 和ecplise ，即在java程序还在测试阶段，但是我想如果你的程序export后应该还会遇到这个问题 报错：Exception in thread "main" java.lang.OutOfMemoryError: Java heap space 报错分析： 这个错误的出现主要是java的虚拟机jvm的内存不够了，通俗点儿说就是java程序运行过程中JVM可以调配使用的内存空间的设置（JVM在启动的时候会自动设置Heap size的值,当然这个值是可以手动指定的) 。 而这个问题出现的根源也是比较多，但是一般来说归结为两点： 1、所谓的内存泄漏（怎么泄漏的，自己找原因），导致你的jvm内存不够使用； 2、处理的数据太大（这个是最主要的原因），也就是你的数据处理太多，jvm一下子搞不定了； 解决方法： 针对错误分析给出解决方法 1、对于内存泄漏而言，当然是去查看自己的程序了，查看你的变量的定义，实例化，等等; 2、对于数据量大，主要的处理是增加jvm的大小，分批处理你要处理的数据; 调整jvm （写的太大会曝出 Error

分类：见Visio图 关于大量数据 导入 是应注意以下几点： 分批导入，导入一批后最后提交(commit)，可以使用jdbc的（executeBatch）批量处理但是注意它的 最大上限 ，否则只会执行一部分sql语句，超过上限的sql会自动丢弃; 注意内存使用(不要出现内存益出， Java heap space; 尽量使用大量导入工具(bcp,sqlLoader)来完成（ 未测试不确定 ） ; 数据量很大时导入时最好不要做太多的判断，这样会影响导入速度； 数据量很大时：是在建表时候添加主键（ 假设主键不是自增长ID列 ）后插入数据，还是插入数据后添加主键，前者主要的问题是大量数据插入速度减慢，如果是频繁的插入操作会导致数据库奔溃；后者的问题也是大量数据的表添加主键（需要删除重复记录，并根据mysql自己的添加主键机制来处理，速度很慢，而且频繁的操作也会导致数据库的奔溃）； 如果原数据表中有索引，先删除索引，待到导入数据后再建立索引；（ 主键是唯一索引的特列，这也是 5.中所述的 ） 由于数据量大的原因，需要配置mysql的 my.ini 文件中相关选项，这个过程中如果不是很明白各个参数之间的相关关系，则需要一个参数一个参数的修改，从而提高mysql的整体性能； insert 语句的处理而言，用StringBuilder代替“+”其性能是个质的提高； 利用jdbc支持的批量插入