如何通过JDBC高效将千万级TSV数据导入MySQL并优化双文件写入效率

针对两个千万级TSV因字段拆分、id非全量匹配无法提前在源文件合并，原「先全量插入再全量更新」流程耗时过长的问题，可落地的优化方案如下：

流式哈希预匹配合并，单次批量入库替代两段式操作 #

• 彻底绕开原流程“先插库再更新”的重型数据库操作，核心逻辑是在应用层完成两个文件的id匹配，拼好完整记录后一次性入库：
  1. 先读取仅包含id、email、phno的第二个TSV，采用固定分块的方式做紧凑哈希映射存储：如果单节点内存充足，直接在内存中把id作为键，对应的email、phno作为值建立映射，1000万条三个字段的记录仅需3-5G内存即可容纳；如果内存不足，就按id的哈希值将记录路由到16-32个本地磁盘分片，匹配时直接定位id对应的分片读取，避免全量扫描。
  2. 再流式读取包含id、name、age的第一个TSV，逐行拿id去之前建立的哈希映射中匹配：匹配成功就把email、phno字段拼接进当前记录，匹配不到就保留空的对应字段。
  3. 拼接好的记录按每批5000-10000条的固定大小攒批，直接批量插入Person表。
• 效率收益：直接消去原流程中全表更新带来的索引维护、行锁、事务日志刷盘的额外开销，整体处理速度比原流程快3-5倍。

保留数据库侧流程，通过原生工具和批量操作压缩耗时 #

如果不想调整预匹配的逻辑，也可以在数据库流程中针对性优化瓶颈：

• 全量导入阶段不使用应用层逐行/小批量拼SQL插入，直接调用数据库原生的批量导入能力：MySQL用LOAD DATA INFILE，PostgreSQL用COPY FROM，这类工具的导入速度比应用层批量插入快10倍以上，1000万条记录的导入耗时可从十几分钟压缩到1分钟内。
• 若必须执行匹配更新，绝不逐行单条更新：先把第二个TSV的内容通过原生导入工具，导入到一个无索引、无约束的临时表，再执行单条集合匹配更新语句UPDATE Person p JOIN tmp_contact c ON p.id = c.id SET p.email = c.email, p.phno = c.phno，这类批量关联更新的速度比逐行更新快两个数量级，执行完成后直接删除临时表即可。
• 导入更新阶段临时移除Person表上的非必要二级索引、外键约束，等全部数据写入完成后再重建索引——索引维护的开销在全量写入阶段能占到总耗时的60%以上，临时关闭可大幅减少重复的索引调整操作。

分片并行处理突破单节点性能上限 #

• 不管是应用层预匹配还是数据库导入流程，都可以按照统一的id路由规则（比如id对16取模），把两个TSV分别拆成16个独立分片，每个分片单独跑“匹配拼接 + 批量入库”的流程，整个流程无跨分片依赖，可完全跑满多核CPU，整体处理耗时可进一步压缩到单节点流程的1/16。
• 这种分片方式完全适配“第二个文件id不全”的场景，拆分时不需要硬拼两个源文件，只需要按规则把两个文件的记录归到对应分片目录，缺id的分片自然没有对应记录，不需要额外的合并操作。

实操注意：存储哈希映射时尽量把id转成长整数类型做键，避免字符串键带来的哈希计算、内存冗余开销；批量入库的批次大小不要设置过小，调整好数据库的报文大小限制后，每批1万条是性能最优区间，过小会拉高网络交互开销，过大会带来过大的事务回滚压力。

内容的提问来源于stack exchange，提问作者Vijay Venkatesh