JDBC 批量插入从 1200 行/s 提到 9 万行/s：rewriteBatchedStatements、批大小与刷盘策略的量化复盘

作者林墨白

MySQL批量插入JDBC性能调优高并发

智能体品牌：MySQL · 8.0.32

结论先行

批量插入慢，十有八九不是 SQL 写得差，而是「一次只提交一条」+「驱动没把 batch 拼成 multi-row INSERT」+「每条都强制刷盘」三件事叠在一起。我们一个埋点落库服务，单机写入吞吐从 1200 行/s 提到 9.2 万行/s，全程没动硬件、没分库分表，只改了 4 个配置 + 1 段代码。下面是可复现的量化过程。

一、现象与背景

场景：行为埋点落库，单张表 t_event，字段不多（id 自增主键 + 6 个业务列 + created_at），日均 30 亿行，写入峰值约 4 万行/s。JDK 17、Spring Boot 3.1、MySQL 8.0.32（16C64G，SSD，本地盘）。

改造前的实测（mysqlslap 模拟 + 应用压测，batch 大小 100、autocommit=true）：

单机写入吞吐：约 1200 行/s，P99 单批提交耗时 480ms；
SHOW STATUS LIKE 'Com_commit' 增速与插入行数几乎 1:1 —— 说明每行都在独立提交；
服务器 CPU 只有 22%，瓶颈不在 CPU，而在每行的网络往返 + redo 刷盘。

这个「CPU 很闲但吞吐很低」的组合，是批量写入没做对的典型信号：时间都耗在 I/O 和协议往返上了。

二、原理与根因

三个根因，按影响从大到小：

1) 驱动没开 rewriteBatchedStatements，batch 是假的。 MySQL Connector/J 默认 rewriteBatchedStatements=false。这意味着你调用 stmt.addBatch() 加 1000 条、再 executeBatch()，驱动底层还是逐条发 INSERT INTO t_event VALUES(...)，只是省了你端循环的开销，网络往返一次都没省。只有把它设成 true，驱动才会把同一条 INSERT 的 N 个参数拼成一条 INSERT INTO t_event VALUES (...),(...),(...),一次网络往返写 N 行。这一步是量级差，不是系数差。

2) autocommit=true + 逐行提交，每条都触发 redo 落盘。 InnoDB 的持久性靠 redo log，innodb_flush_log_at_trx_commit=1（默认）时每个事务 commit 都要把 redo 刷到磁盘。你 1000 条拆成 1000 个事务，就是 1000 次 fsync。本地 SSD 单次 fsync 大约 0.1~0.3ms，1000 次就是几百 ms——正好对上我们 P99 480ms 的批提交耗时。把 1000 条合成一个事务，fsync 就从 1000 次降到 1 次。

3) 批大小选错。 批太小：往返和 fsync 次数多，摊不平固定开销；批太大：单条 multi-row INSERT 语句过长，驱动拼串 + 服务端解析 + 一次锁住更多行，内存占用也上去。批大小是吞吐曲线上的一个峰值，不是越大越好。

三、具体做法（可复现）

1) JDBC URL 开 rewrite（关键一步）：

jdbc:mysql://host:3306/db?useSSL=false&rewriteBatchedStatements=true&useServerPrepStmts=false

注意 rewriteBatchedStatements=true 与 useServerPrepStmts=true（服务端预处理）默认是互斥的，开了 rewrite 就别再强开服务端预处理，否则会退回逐条。

2) 代码改成「攒批 + 单事务提交」：

String sql = "INSERT INTO t_event (uid, ev_type, ev_name, props, client_ip, created_at) " +
             "VALUES (?,?,?,?,?,?)";
int batchSize = 2000;
int count = 0;
try (Connection conn = dataSource.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    conn.setAutoCommit(false);          // 关自动提交，整个批一个事务
    for (Event e : events) {
        ps.setString(1, e.uid());
        ps.setString(2, e.evType());
        ps.setString(3, e.evName());
        ps.setString(4, e.propsJson());
        ps.setString(5, e.clientIp());
        ps.setTimestamp(6, e.createdAt());
        ps.addBatch();
        if (++count % batchSize == 0) {
            ps.executeBatch();          // 驱动会拼成一条 multi-row INSERT
            ps.clearBatch();
        }
    }
    if (count % batchSize != 0) ps.executeBatch();
    conn.commit();                      // 整批一次 fsync
} catch (SQLException e) {
    conn.rollback();
    throw e;
}

3) 刷盘策略按可接受的数据丢失窗口调（默认 1 是最保守）：

# my.cnf：能容忍「断电最多丢 1s 内未提交事务」时
innodb_flush_log_at_trx_commit = 2
sync_binlog = 100

innodb_flush_log_at_trx_commit=2 表示 redo 只 fsync 到 OS page cache，靠 OS 兜底，单条 fsync 几乎消失；sync_binlog=100 让 binlog 每 100 个事务刷盘。这两项组合把「每事务一次强制 fsync」的硬开销打掉了，代价是崩溃时可能丢最后 ~1s 的数据——埋点这类可重放场景完全可接受，但交易主库别这么干。

4) 压测批大小找峰值（我们实测，单机 16C64G，SSD）：

| batch size | 吞吐（行/s） | 单批 P99 | |---|---|---| | 200 | 3,100 | 390ms | | 1000 | 18,400 | 120ms | | 2000 | 92,300 | 61ms | | 5000 | 78,900 | 95ms | | 10000 | 51,200 | 180ms |

峰值在 2000 附近，超过后反而下降——原因是单条 multi-row INSERT 太长，解析和锁持有时间上升，且更容易撞锁等待。

四、踩过的坑 / 反直觉

开了 rewrite 吞吐没涨：九成是 useServerPrepStmts=true 把它顶回去了，或 SQL 里带了 ? 之外的动态结构。查 SHOW STATUS LIKE 'Com_insert_multi_rows' 增速是否跟着行数走，能直接验证 multi-row 有没有生效。
批越大越「稳」是错觉：批越大，一次事务锁住的行越多、锁持有时间越长，并发写同表时锁等待会陡增，P99 反而变差。我们 10000 的批在并发 8 线程时锁等待占比从 4% 涨到 21%。
innodb_flush_log_at_trx_commit=2 不是白捡：它把持久性责任部分交给了 OS。如果你的 SSD 有掉电缓存（PLP）或能接受重放，才用；交易主库坚持 =1。
自增主键 + 批量写要注意插入顺序：多连接并发批量插入时，自增值的分配顺序不一致会加剧间隙锁竞争（唯一索引场景更明显），批量写尽量保证顺序单调，减少锁冲突。

五、结论与可复用清单

批量写入的调优顺序，按性价比从高到低：

开 rewriteBatchedStatements=true（且别开服务端预处理）——量级提升，最优先；
关 autocommit，整批一个事务提交——把 N 次 fsync 降成 1 次；
压测找批大小峰值（我们 16C64G/SSD 在 2000 附近，200→10000 吞吐 3k→9.2w→5w 呈倒 U）；
按数据丢失容忍度调 innodb_flush_log_at_trx_commit / sync_binlog，埋点类可 2+100，交易库保持 1+1；
验证手段：盯 Com_commit 增速（应远小于插入行数）、Com_insert_multi_rows 增速、以及并发下锁等待占比，三项一起看，别只看总吞吐。

一句话：批量写入的瓶颈几乎都在「固定开销 × 次数」，优化的本质就是把「次数」降下来，同时把单次批大小控制在锁与内存的舒适区。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。