1. 为什么“文本文件导入数据库”是个值得聊的话题但凡做过几年业务系统开发的人几乎都绕不开一个场景业务方甩过来一个几十兆甚至几个G的文本文件里面是订单流水、用户名单、设备日志或者对账明细要求你“尽快入库后面要出报表”。这个需求听起来简单到不值一提但真正动过手的人都知道坑远比想象中多——编码不对导致中文乱码、字段分隔符和内容冲突、几百万行数据一次性读进内存直接OOM、批量插入没开事务导致慢得像蜗牛、导入到一半失败还得从头再来。我这些年处理过的文本导入任务小到几千行的配置清单大到上千万行的交易流水踩过的坑基本能写一本小册子。所以这篇内容我打算把“用Java从文本文档读取数据存入数据库”这件事从头到尾拆开讲一遍不只是给你一段能跑的代码更想把每一步背后的取舍逻辑讲清楚为什么用缓冲流而不是普通流、为什么批量插入要配合事务、为什么有时候宁可先落临时表再清洗。适合刚入行的开发者照着复现也适合有经验的同行对照检查自己的实现有没有遗漏。核心关键词就三个文件读取、数据解析、批量入库。这三个环节任何一个处理不好整个导入任务都会出问题。下面我按实际项目里的推进顺序一层层展开。2. 整体方案设计与技术选型思路2.1 先想清楚数据流向再动手写代码很多人拿到需求第一反应是打开IDE就开始写BufferedReader结果写到一半发现字段对不上、空行没处理、异常没捕获返工重来。我的习惯是先在纸上或者注释里把数据流画清楚源文件 → 逐行读取 → 行解析成对象 → 攒批 → 批量写库 → 提交事务 → 记录结果这条链路里每一环都有它的职责不能混在一起。比如“逐行读取”只负责把字节变成字符串“行解析”只负责把字符串变成结构化对象“批量写库”只负责把对象集合塞进数据库。职责分清楚了后面排查问题的时候你才知道该看哪一段。2.2 技术选型的几个关键决策第一用原生JDBC还是ORM框架如果是纯导入场景我强烈建议用原生JDBC的PreparedStatement配合addBatch()。原因很简单导入任务通常追求吞吐量ORM框架的实体映射、一级缓存、脏检查这些机制在这个场景下全是负担。我实测过一个百万行级别的导入原生批量插入比某主流ORM快了将近三倍。第二文件读取用哪种流文本文件读取必须用带缓冲的字符流。FileReader本身不带缓冲每读一个字符都可能触发一次系统调用慢得离谱。正确姿势是BufferedReader包装InputStreamReader并且显式指定字符集。这里有个细节InputStreamReader负责字节到字符的解码BufferedReader负责减少IO次数两者职责不同缺一不可。第三事务边界怎么划这是最容易被忽视的地方。如果你把整个文件的导入放在一个事务里一旦中途某行数据有问题整个事务回滚前面几百万行的努力全白费。但如果你每插一行就提交一次数据库的日志写入压力会让你怀疑人生。合理的做法是分批提交比如每5000行提交一次兼顾吞吐量和容错性。2.3 一个容易被忽略的前置问题文件到底长什么样在写任何代码之前我一定会先做一件事用文本编辑器打开源文件看它的真实面貌。具体看什么编码格式是UTF-8还是GBK有没有BOM头用file命令或者编辑器的编码检测功能确认。分隔符是逗号、制表符还是竖线字段内容里会不会出现同样的符号如果会有没有引号包裹规则行尾符是\n、\r\n还是\r跨平台文件混用的情况很常见。首行是表头还是数据表头需不需要跳过空行和注释行有没有需要过滤的行这些问题看起来琐碎但每一个都可能导致导入失败或者数据错乱。我见过最离谱的一个文件前1000行是正常数据第1001行开始突然换了一种分隔符据说是两个人分别导出的文件被直接拼接了。3. 核心细节解析与实操要点3.1 文件读取缓冲、编码与逐行处理先看读取部分的标准写法public void readFile(String filePath, String charsetName) throws IOException { try (BufferedReader reader new BufferedReader( new InputStreamReader(new FileInputStream(filePath), charsetName), 8192)) { String line; int lineNumber 0; while ((line reader.readLine()) ! null) { lineNumber; if (line.trim().isEmpty()) { continue; } processLine(line, lineNumber); } } }这段代码里有几个值得说的点。try-with-resources保证流一定被关闭避免文件句柄泄漏。缓冲区大小设成8192是经验值默认的也是8192但显式写出来更清晰如果文件特别大可以调到16384或32768不过收益递减明显。readLine()会去掉行尾的换行符但不会去掉行首行尾的空格所以判断空行要用trim()。注意readLine()遇到超长行比如某行有几十万个字符时会有内存问题因为它在内部会不断扩容StringBuilder。如果源文件可能存在超长行需要改用按字符读取并手动拼接的方式或者设置合理的行长度上限并抛异常。关于编码我踩过最深的坑是文件明明是UTF-8但用系统默认编码读出来中文全是问号。原因是Windows中文版的默认编码是GBK而new InputStreamReader(stream)不传编码参数时用的就是平台默认编码。所以永远显式指定编码不要偷懒。3.2 行解析分隔符、字段映射与类型转换解析这一环的核心是把一行字符串拆成字段数组再映射到数据库表的列。最朴素的做法是line.split(,)但这里有个大坑如果字段内容本身包含逗号比如地址“北京市,朝阳区”split就会拆错。处理这种情况有两种方案。如果文件是标准CSV格式字段用双引号包裹内部逗号不转义需要写一个状态机来解析不能简单split。如果文件是自定义格式且业务方保证字段内不含分隔符那split够用但要在代码里加断言校验字段数量。private static final int EXPECTED_FIELD_COUNT 6; public UserRecord parseLine(String line, int lineNumber) { String[] parts line.split(\\|, -1); if (parts.length ! EXPECTED_FIELD_COUNT) { throw new IllegalArgumentException( 第 lineNumber 行字段数异常期望 EXPECTED_FIELD_COUNT 实际 parts.length); } UserRecord record new UserRecord(); record.setUserId(Long.parseLong(parts[0].trim())); record.setUserName(parts[1].trim()); record.setAge(Integer.parseInt(parts[2].trim())); record.setRegisterTime(parseDate(parts[3].trim())); record.setAmount(new BigDecimal(parts[4].trim())); record.setRemark(parts[5].trim()); return record; }split的第二个参数传-1很重要它保证末尾的空字段不会被丢弃。比如a|b|用split(\\|)得到的是[a,b]用split(\\|, -1)得到的是[a,b,]。在导入场景里末尾空字段往往代表某个可空列丢了就会导致字段错位。类型转换是另一个重灾区。Long.parseLong遇到空字符串或者非数字会抛NumberFormatExceptionBigDecimal的构造器遇到空串也会抛异常。我的做法是封装一层安全的转换方法把行号和字段名带进异常信息里这样排查问题时能直接定位到具体哪一行的哪个字段。3.3 批量入库PreparedStatement与事务配合入库部分的核心是PreparedStatement的批量操作。先看代码骨架public void batchInsert(ListUserRecord records, Connection conn) throws SQLException { String sql INSERT INTO user_info (user_id, user_name, age, register_time, amount, remark) VALUES (?, ?, ?, ?, ?, ?); try (PreparedStatement ps conn.prepareStatement(sql)) { for (UserRecord record : records) { ps.setLong(1, record.getUserId()); ps.setString(2, record.getUserName()); ps.setInt(3, record.getAge()); ps.setTimestamp(4, new Timestamp(record.getRegisterTime().getTime())); ps.setBigDecimal(5, record.getAmount()); ps.setString(6, record.getRemark()); ps.addBatch(); } ps.executeBatch(); } }这里有几个关键参数需要调优。首先是批大小也就是每多少条执行一次executeBatch()。太小了频繁和数据库交互太大了内存占用高且失败回滚代价大。我一般从1000开始试根据数据库类型和网络延迟调整MySQL下500到2000都比较常见Oracle可以到5000。其次是事务提交频率。批大小和提交频率可以一致也可以不一致。比如每1000条执行一次executeBatch()每5000条提交一次事务这样5个批次共享一个事务减少日志刷盘次数。int batchSize 1000; int commitSize 5000; int count 0; conn.setAutoCommit(false); for (UserRecord record : allRecords) { fillStatement(ps, record); ps.addBatch(); count; if (count % batchSize 0) { ps.executeBatch(); ps.clearBatch(); } if (count % commitSize 0) { conn.commit(); } } ps.executeBatch(); conn.commit();注意executeBatch()之后要调用clearBatch()否则已执行的批次会一直留在内存里数据量大了照样OOM。这个细节很多教程都不提但实际项目中非常关键。3.4 连接池与资源管理导入任务通常是一次性的批处理作业不需要长期持有连接。但即便如此也不要用DriverManager.getConnection()每次现开连接因为批量插入过程中可能涉及多次提交连接复用能省下不少握手开销。用连接池比如HikariCP配置一个最小连接数即可任务结束后关闭池。资源关闭的顺序也有讲究先关PreparedStatement再关Connection且都要放在finally或者try-with-resources里。如果用了连接池Connection.close()实际上是归还连接而不是真正关闭所以不用担心频繁开关的开销。4. 完整实操流程与关键环节实现4.1 环境准备与依赖配置假设我们用Maven管理项目核心依赖只有两个数据库驱动和连接池。以MySQL为例dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId version8.0.33/version /dependency dependency groupIdcom.zaxxer/groupId artifactIdHikariCP/artifactId version5.0.1/version /dependency数据库驱动版本要和数据库服务端版本匹配版本差异过大可能出现时区、字符集、SSL握手等兼容问题。连接池的配置项里maximumPoolSize设成5到10就够了导入任务本身是单线程顺序写连接开多了反而浪费。4.2 建表与字段设计建表时有两个原则。第一导入期间先去掉非必要的索引和约束。如果目标表上有多个唯一索引每插一行数据库都要去维护索引树速度会慢一个数量级。我的做法是先建一个结构相同但没有索引的临时表导入完成后再INSERT INTO ... SELECT到正式表或者导入后再补建索引。第二字段类型要留足余量。源文件里的字符串长度往往不可控VARCHAR(50)很可能在第3000行就爆了。导入阶段可以先用VARCHAR(500)甚至TEXT兜底后续再根据实际数据分布收紧。CREATE TABLE user_info_staging ( user_id BIGINT, user_name VARCHAR(200), age INT, register_time DATETIME, amount DECIMAL(18, 4), remark VARCHAR(1000) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;4.3 主流程串联把前面几部分串起来主流程大概长这样public class TextToDbImporter { private static final int BATCH_SIZE 1000; private static final int COMMIT_SIZE 5000; public ImportResult importFile(String filePath, String charsetName) { ImportResult result new ImportResult(); ListUserRecord buffer new ArrayList(BATCH_SIZE); try (BufferedReader reader new BufferedReader( new InputStreamReader(new FileInputStream(filePath), charsetName))) { Connection conn dataSource.getConnection(); conn.setAutoCommit(false); PreparedStatement ps conn.prepareStatement(INSERT_SQL); String line; int lineNumber 0; int successCount 0; while ((line reader.readLine()) ! null) { lineNumber; if (line.trim().isEmpty()) continue; try { UserRecord record parseLine(line, lineNumber); fillStatement(ps, record); ps.addBatch(); successCount; if (successCount % BATCH_SIZE 0) { ps.executeBatch(); ps.clearBatch(); } if (successCount % COMMIT_SIZE 0) { conn.commit(); } } catch (Exception e) { result.addError(lineNumber, line, e.getMessage()); } } ps.executeBatch(); conn.commit(); result.setSuccessCount(successCount); } catch (Exception e) { // 整体异常处理 } return result; } }注意这里我把单行解析的异常捕获放在了循环内部这样一行数据有问题不会中断整个导入而是记录到错误列表里继续处理。这是生产环境导入任务的标配——永远假设源数据是脏的。4.4 参数计算与调优过程批大小和提交频率不是拍脑袋定的我一般会做一个小规模压测。取1万行数据分别用批大小100、500、1000、2000、5000跑一遍记录耗时和内存占用。经验数据是批大小从100提到1000耗时通常能降40%左右从1000提到5000收益就很小了但内存占用会明显上升。所以1000是个比较稳妥的默认值。提交频率的确定要考虑失败重试的成本。如果每1000行提交一次失败时最多丢1000行如果每10万行提交一次失败时前面的工作可能全白费。我通常把提交频率设成批大小的3到5倍。5. 常见问题与排查技巧实录5.1 中文乱码问题排查乱码是文本导入最高频的问题排查思路是逐层确认编码。第一步确认文件本身的编码用十六进制编辑器看前几个字节UTF-8的BOM是EF BB BFGBK没有BOM但中文双字节高位有特征。第二步确认读取时指定的编码和文件一致。第三步确认数据库连接串里的characterEncoding参数和表的字符集一致。三层里任何一层不匹配都会乱码。提示如果文件带BOM头用UTF-8读取时第一行的第一个字段会多出一个不可见字符导致字段解析或数据库匹配失败。处理办法是读取时判断首字符是否为\uFEFF并去掉。5.2 内存溢出与性能瓶颈导入大文件时OOM通常有两个原因。一是把整个文件读进了内存比如用Files.readAllLines()这个在文件超过几十兆时就会出问题必须改成流式逐行读。二是批量列表没有及时清理addBatch()之后忘了clearBatch()或者把解析后的对象全攒在一个大List里最后统一插入。解决办法就是前面说的分批处理让内存占用保持恒定。性能瓶颈方面如果发现导入速度远低于预期按这个顺序排查数据库索引是否过多、是否开了自动提交、批大小是否过小、网络延迟是否过高、目标表是否有触发器。我遇到过一次导入特别慢最后发现是目标表上有个触发器在每次插入时往另一张表写日志关掉触发器后速度提升了十几倍。5.3 常见问题速查表问题现象可能原因排查方向解决手段中文变问号编码不一致文件编码、读取编码、库表字符集三层统一为UTF-8首字段多乱码UTF-8 BOM头十六进制查看文件头读取时剥离\uFEFF字段错位分隔符冲突或空字段被丢检查字段内容是否含分隔符用状态机解析或split传-1导入中途OOM全量读入内存或批次未清理检查是否用了readAllLines改流式读取clearBatch速度极慢索引多、自动提交、批太小查看表索引和连接配置去索引、关自动提交、调大批部分行失败脏数据查看错误行内容单行异常捕获错误记录事务回滚全丢单事务太大检查提交频率分批提交5.4 几个独家避坑经验第一导入前先备份目标表。我吃过一次亏导入脚本写错了字段映射把用户名的值插到了手机号列等发现的时候已经覆盖了几十万行。后来我的习惯是导入前先CREATE TABLE xxx_bak AS SELECT * FROM xxx出问题能快速回滚。第二给导入任务加进度日志。每处理1万行打一条日志记录已处理行数和耗时。这样任务卡住的时候你能知道卡在哪个阶段而不是干等着。第三错误行单独落文件。解析失败的行不要只记在内存里实时追加写到一个error_lines.txt里包含行号和原始内容。导入结束后业务方可以拿着这个文件去修正源数据然后只重导错误行。第四注意数据库的max_allowed_packet限制。批量插入时如果单次批次的数据量超过这个参数数据库会直接拒绝。MySQL默认是4MB或64MB批次特别大时需要调大这个参数或者减小批大小。第五时间字段的时区问题。如果源文件里的时间是字符串解析成java.util.Date再存Timestamp中间涉及时区转换。如果数据库和JVM时区不一致存进去的时间可能差几个小时。稳妥的做法是全程用LocalDateTime配合JDBC 4.2的setObject避开时区干扰。6. 从能跑到好用几个进阶优化方向6.1 并行导入的可行性分析单线程导入受限于磁盘IO和数据库写入速度如果文件特别大可以考虑并行。但并行有个前提数据之间没有顺序依赖且数据库能承受并发写入。做法是把文件按行数切分成多个段每个线程读一段、解析一段、插入一段。不过要注意多个线程共用一个Connection是不行的每个线程需要独立的Connection。而且并行度不是越高越好数据库的写入瓶颈往往在磁盘开4个线程和开8个线程可能没区别。6.2 用数据库原生导入工具做对比很多数据库自带高效的文本导入工具比如MySQL的LOAD DATA INFILE速度比JDBC批量插入快一个数量级。那为什么还要用Java写因为Java方案灵活可以在导入过程中做复杂的数据清洗、字段转换、多表关联还能和现有系统集成。我的经验是如果只是单纯的数据搬运且格式规整优先用数据库原生工具如果需要业务逻辑处理才用Java方案。两者不是替代关系而是互补。6.3 导入结果的可观测性一个成熟的导入任务应该输出一份完整的报告总行数、成功行数、失败行数、耗时、平均每秒处理行数、失败行的分布比如前10条错误详情。这份报告可以存到数据库的导入日志表里方便后续审计和问题追溯。我现在的习惯是每次导入都生成一个import_report_时间戳.json内容包括上述指标和错误明细的文件路径。6.4 幂等性设计如果导入任务可能被重复执行比如失败后重跑要考虑幂等性。最简单的做法是导入前先按某个业务键删除已有数据再插入。或者用INSERT ... ON DUPLICATE KEY UPDATEMySQL或MERGE INTOOracle做upsert。如果源数据本身有唯一标识也可以在导入前先查一遍已存在的ID集合过滤掉重复的。具体选哪种取决于数据量和业务容忍度。7. 一些个人体会这套“读文件-解析-批量入库”的流程我前后写过不下二十遍每次项目不同、文件格式不同、数据库不同但骨架始终是那几块。真正拉开差距的不是代码写得多花哨而是对边界情况的处理空文件怎么办、只有表头怎么办、字段数不对怎么办、编码不对怎么办、导入到一半数据库连接断了怎么办。这些问题在demo里永远不会出现但在生产环境里一定会出现。我现在写这类任务第一版代码一定是“能跑就行”然后立刻拿真实数据或者故意构造的脏数据去压把各种异常都触发一遍再根据暴露出来的问题加固。这个过程比一开始就追求完美设计要高效得多。另外别小看日志和报告的价值导入任务出问题时一份清晰的错误记录能帮你省下几个小时的排查时间。最后分享一个小技巧如果源文件的格式经常变比如业务方每次导出的列顺序不一样可以在文件首行加一个表头解析时先读表头建立“列名到索引”的映射后续按列名取值而不是按固定下标。这样格式变了只需要改表头代码不用动。这个设计在对接多个业务方的场景下特别省心。