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

hash，b+，哪种实现方便用那种
你这个索引不是那种要和插入更新绑定的真正数据库索引，只是导入数据需要的查询索引而已，所以选择一个合适的数据结构与装入要索引的项目就行，没你想的那么难，数据仓库里面更新fact表的维度字段就可以这么做
你了解数据库插入数据要做哪些事、数据库索引的原理和大致实现、基本的磁盘特性和性能特点和数据库如何通过索引访问实际数据就明白了
索引不只是插入成本高，如果读取较多数据，走索引也是不合适的，读多大比例不合适取决于记录大小/块大小，索引提高查询只是相对查询极少数据而言，但如果你查1张表10%以上的数据，而记录很小块很大根本就不应该走索引，除非你的查询字段全部集中在索引上

你就不能把字写的有格式点吗，这么多挤一起

基本上关系型数据库的索引都会有这种问题。因此，插入和更新大批量数据时，最好把索引先禁用掉。数据操作完毕再rebuild。

这个。。呃。。。好像是常识吧。

虽然JVM默认将字符串类的“+”操作用StringBuilder()替换实现，但是其替换方式是简单的替换，如果在循环中使用“+”操作，会创建大量StringBuilder()对象，影响效率。

肯定有这方面的原因，至于是不是全因为这个就不知道了，看来Oracle确实还是高MySQL不少。

这种需求最好的将日志转换为oralce能做copy的文本格式（类似于mysql的load 列中间用,分割）
然后删除索引 执行copy命令 再重新建立索引。和你这样的做法速度不是一个级别的

但是重建索引的速度也是很慢的，因为有大量的数据存在。所以自己实现索引还是不错的选择。

对头。数据量大的时候重建索引那是相当的慢。

这么大的数据量，能不能先进性表分区再评估索引对插入性能的影响呢。