主要分为：
介绍出现场景（为什么市场有一些数迁工具不采用）介绍迁移的方案（为了应对这种独特的方式采取什么方案）中间遇到的问题（开发执行，到上线过程中遇到的问题和解决方案）1.介绍：本次数据迁移与一般从单个系统升级换数据库完全不一样，本次数据迁移用于从五个系统中抽取出新出现一个系统所需要的数据。由于这五个系统中会存在系统与系统之间的联系与业务逻辑，系统与系统间数据存在覆盖（就会涉及到数据以哪个为准），数据的补全，所以决定单独抽取一个应用，用于数据迁移。 2.具体数据量:千万级数据迁移
在迁移系统中找出想要我们新系统所需要的表，在从旧表中找出所需要的字段，看它对应新系统中的哪个表或者哪个字段（如下图） 1、通过oracle spool 导出源系统数据xxx.txt（格式：UTF-8）（在spool语句中确认导出格式如字段与字段之间用什么隔离） 2、逐笔解析文件数据（根据图一的映射关系逐笔解析，解析成格式为map<表名，map<字段名，字段值>>） 3、判断记录是否存在（分别对五个系统设置不同的入口，和不同的业务逻辑处理） 4、若存在则判断字段是否存在，字段不存在则组装改操作SQL（对map进行操作根据新系统中的数据进行合理处理） 5、若不存在则组装写操作SQL 6、执行SQL 7、更新数迁控制表，失败明细表，关键字段合并记录表、操作流水表（对每一笔处理都进行日志等操作）
1、效率问题：开始采取的是单线程实现业务场景，发现效率问题很大，后面采用线程池，多线程技术（对txt文件中的每一行数据的前后处理无顺序要求），对文件的读取采用直接全加载进内存（瓶颈在与对数据库的操作） 2.数据库效率问题:由于这次数迁不能无脑插入，需要对库中数据进行判断校验，存在对数据库的访问效率，解决方案：开启慢查询对数据库的sql进行分析，对效率低的进行优化（sql优化，索引优化） 3.内存问题，第一点说明为了加快读取文件速度，采取了将文件全加载进内存的方案，后面发现文件大小超标，后面采取依次只读取一定的数量进内存（使用jdk自带的内存分析工具jconsole.exe进行分析，找到这个一定量的边界值），处理完后在读取。 4.上线时序问题（数据迁移上线线上是不停产得，可能在迁移过程中还有新数据进行增加）
