大量数据导入数据库问题总结（成也索引，败也索引）

老板项目需要从类似日志的文本文件中提取出元数据，然后放到数据库中为数据挖掘做处理。设计数据库为两张表，初步估计第一张表是千万级的数据，第二张表是亿级数据。面对这么大数据量的导入需求，分析设计高效的程序就显得很有必要了，磨刀不误砍柴功嘛！
首先考虑的是提高IO效率，毕竟现在计算机cpu高主频，多核心的环境下硬盘IO才是瓶颈。在文件读取上提高程序效率，比如用StringBuilder代替“+”等。
其次是提高内容分析的效率，在设计内容分析程序的时候就得为大数据量和多线程考虑。1.减少复杂操作，比如提取文本文件少用正则表达式匹配，尽量定位下标，利用下标截取字符串；还有减少循环次数，尽量减少循环次数，毕竟是有上亿条数据，多一次单层循环最少就多计算若干亿次。2.程序少用或不用共享数据，例如处理类中没有类属性，这样能简化多线程程序难度。3.合理设计减少除了插入之外的其他与数据库交互行为。
最后是数据库插入程序。利用jdbc支持的批量插入，手动控制事务。这样优化的程序能达到多线讲程并发高效插入。
最后是记录下教训。因为数据是为数据挖掘准备的，在处理过程中需要频繁查询大量字段，所以数据库设计了对应的索引，索引可以极大的提高查询效率。本来为了查询方便的索引没想到确成了程序的噩梦。程序刚开始运行的时候速度就没有想象中的理想，随着程序运行，效果越来越差，效率奇低，每秒仅10条左右的速度，这到猴年马月才能导完啊！于是分析程序，开始考虑是内容提取程序的问题，原来用的是java调用C程序的动态链接库，觉得可能会有效率问题，于是用java重写原来的内容提取部分程序，单元测试效率不错。没想到整体程序还是奇慢，没多少行的代码手动检查了N遍。最后才怀疑到了数据库索引的问题，毕竟mysql索引用的是B+树，频繁插入会不断更改树的结构，这很影响效率，而且会打断批量插入的效果，于是走头无路的情况下试着删除了索引，发现速度一下就上来了。没想到当初自以为聪明设置的几条索引，让自己用了好几天的时间找bug。真是“成也索引败也索引”。大数据量导入正确的做法应该先导删除索引，待数据导完后再创建索引。

你说的很对，大量写入数据应该先删除索引

概念：OLAP DW
技术：SQLLoad InfoBright.....或许还有更多Framework式的解决方案

求速度的话，如果导入过程中一定要索引特性不要用数据库的，自己实现，即使所有索引块都装入了内存buffer，速度也比不过自己实现的结构
加了物理索引实际就是将插入这种顺序io变成了每条插入都是随机io当然会慢

我想问下，当你发现插入多少数据量的时候，发现插入速度慢这么多？

那张亿级表大概有千万条数据的时候发现的这个问题。你这问题挺关键，应该补充到帖子里

请问你自己是否实现过索引。索引实现的代码难度还是相当高的，另外为什么个人实现的索引要比数据库自带的索引速度快？

"比如用StringBuilder代替“+”等。 "

-_______________-

看了下, 看来导入难度不大啊....

我记得Oracle在生成数据导入导出脚本的时候都有关闭索引的语句，是不是也是因为这个问题？