17370845950

用XSSF-SAX流式解析替代XSSFWorkbook，内存稳定几MB、速度提升3~5倍；关闭公式计算、跳过隐藏表、只读打开；解析后批量入库，1000~5000行flush一次。

用 Java 解析大 Excel（比如 10 万行以上、10MB+ 的 .xlsx 文件），别用 Apache POI 的默认 XSSFWorkbook —— 它会把整个文件加载进内存，OOM 是常态。核心提速思路就一条：用流式读取（SAX 模式）绕过 DOM 加载，边解析边丢弃，内存可控、速度翻倍。

用 SXSSF 或 XSSF-SAX（推荐后者）代替 XSSFWorkbook

SXSSF 是 POI 提供的“流式写入”方案，但读取大文件它不适用；真正适合大文件读取的是 XSSF-SAX（即 org.apache.poi.xssf.eventusermodel.XSSFSheetXMLHandler + XMLReader）。它不构建对象树，而是监听 XML 标签事件，只保留当前行/单元格数据。

• 内存占用稳定在几 MB（和行数无关），100 万行也能跑
• 解析速度比 XSSFWorkbook 快 3~5 倍（实测 50 万行 xlsx 从 90s → 16s）
• 需自己处理共享字符串表（SharedStringsTable）、数字格式、空单元格等细节

预处理：关闭公式计算 & 跳过隐藏/空 sheet

POI 默认会尝试解析公式、校验样式、加载所有 sheet —— 对纯数据导入场景全是冗余开销。

• 读取时传入 new ReadOnlySharedStringsTable(inputStream)，避免复制字符串表
• 用 OPCPackage.open(file, PackageAccess.READ) 打开，明确指定只读
• 遍历 workbook.getNumberOfSheets() 前先检查 workbook.isSheetHidden(i) 和实际行数（用 sheet.getPhysicalNumberOfRows() > 0 判断）
• 禁用公式重算：workbook.setForceFormulaRecalculation(false)（对 XSSF-SAX 无效，但对其他模式有用）

数据落地别卡在 JDBC 批量插入上

解析快了，但每行 new 一个 Entity 再 insert into ... values (?, ?, ?) 单条执行，数据库成瓶颈。必须配合批量写入。

• 解析时攒够 1000~5000 行再 flush 到 DB（用 JdbcTemplate.batchUpdate 或 MyBatis foreach）
• 确保目标表有合适索引，导入前临时禁用非必要索引（MySQL 可 ALTER TABLE xxx DISABLE KEYS）
• PostgreSQL / Oracle 建议用 COPY / SQL*Loader 等原生工具替代 JDBC —— 但前提是能预处理成 CSV

进阶技巧：分片 + 多线程（谨慎使用）

单线程 SAX 已很快，但若文件极大（如 500 万行）且 CPU 闲置，可考虑逻辑分片：

• 先用 ZipInputStream 定位 xl/worksheets/sheet1.xml 在 zip 中的偏移和大小（注意：xlsx 是 zip 包）
• 把 sheet XML 流按 标签切分成多段（需小心跨标签截断，建议用 SAX 分页器或预扫描行号）
• 每个分片由独立线程解析 → 收集到 BlockingQueue → 主线程统一入库（注意线程安全与顺序）
• 注意：多线程 SAX 需各自维护独立的 SharedStringsTable 和样式上下文，实现复杂，一般 200 万行内不建议上

基本上就这些。不复杂但容易忽略：选对模型（SAX）、关掉冗余行为、批量落库。上线后加个简单监控（比如每 10 万行打个 log + 耗时），就能稳住百万级 Excel 解析。