如何优化Spring Boot场景下高频调用的MySQL单条插入性能

当前单条消息触发一次insert的模式，在高并发海量用户场景下，会产生大量网络IO、事务提交、磁盘刷盘开销，很容易成为系统瓶颈，可按以下层级优化，Spring Data生态完全支持批量插入能力。

一、数据库基础参数调优 #

先从数据库端把基础性能拉满，不需要改业务代码就能拿到明显提升：

• 调整InnoDB刷盘策略：将innodb_flush_log_at_trx_commit设置为2，事务提交时仅把redo log写入操作系统缓存，每秒统一刷盘，崩溃场景最多丢失1秒数据，完全适配聊天消息的可靠性要求，插入性能相比默认值1可提升2-3倍；配合将sync_binlog设置为1000，减少binlog刷盘次数。
• 保持现有自增主键配置：自增主键是顺序写入，InnoDB聚簇索引下不会触发页分裂，插入开销最低，不要替换为无序的UUID类主键。
• 提前规避唯一键冲突：表上的room_id + message_no唯一键，业务侧生成message_no时要保证同房间内连续递增，避免插入时触发唯一键校验失败的回滚开销。

二、Spring Data 批量插入落地实现 #

Spring Data（含Spring Data JPA、JdbcTemplate）完全支持批量插入，核心是要把驱动和框架的批量开关打开，不要用框架默认的伪批量逻辑：

1. 首先修改JDBC连接串，加入参数rewriteBatchedStatements=true，这是MySQL JDBC驱动的核心开关，开启后驱动才会把多条插入语句重写为insert into mq_message values (...),(...),(...)的单条多值形式，否则就算调用批量API，驱动还是会逐条发送SQL，没有性能收益。
2. 如果用Spring Data JPA，在配置文件中加入以下参数：

spring:
  jpa:
    properties:
      hibernate:
        jdbc:
          batch_size: 500
        order_inserts: true

配置后Hibernate会自动把同表插入凑够500条再统一发送，同时对插入语句做排序，减少SQL类型切换开销。注意默认的saveAll()方法会先逐行查询主键判断是新增还是更新，属于伪批量，要实现真批量建议直接写原生插入语句，或者直接用JdbcTemplate做批量操作，可控性更高：

// 攒批后执行批量插入示例
public void batchInsert(List<MqMessage> messageList) {
    String sql = "insert into mq_message (room_id, message_no, previous_message_no, post_user_id, json_body, is_deleted, is_isolated) " +
            "values (?,?,?,?,?,?,?)";
    jdbcTemplate.batchUpdate(sql, new BatchPreparedStatementSetter() {
        @Override
        public void setValues(PreparedStatement ps, int i) throws SQLException {
            MqMessage msg = messageList.get(i);
            ps.setString(1, msg.getRoomId());
            ps.setInt(2, msg.getMessageNo());
            ps.setInt(3, msg.getPreviousMessageNo());
            ps.setString(4, msg.getPostUserId());
            ps.setString(5, msg.getJsonBody());
            ps.setByte(6, msg.getIsDeleted());
            ps.setByte(7, msg.getIsIsolated());
        }
        @Override
        public int getBatchSize() {
            return messageList.size();
        }
    });
}

3. 攒批逻辑实现：用有界内存队列（比如ArrayBlockingQueue）做消息缓冲，启动独立的消费线程，满足「攒够300条消息」或者「距上次刷库超过100ms」任意一个条件就触发一次批量插入，同时做好队列长度监控、服务优雅停机逻辑，停机前把队列中剩余消息全部刷库再退出进程，避免消息丢失。

三、大规模场景进阶优化 #

如果业务量级继续增长，可以加架构层优化：

• 写入削峰：消息到达后先写入Redis做一级缓冲，峰值流量由Redis承接，再异步批量刷入MySQL，避免突发流量打垮数据库。
• 分库分表：按room_id做哈希分表，把不同频道的消息打散到不同物理表，单表数据量控制在千万级以内，保证插入性能稳定。
• 读写分离：消息写入走主库，历史消息查询走从库，避免查询请求占用主库IO资源影响写入性能。

注意事项：批量插入的单批次大小建议控制在200-1000条，不要设置过大，否则会触发MySQL的max_allowed_packet长度限制报错，同时单次事务过大会导致锁持有时间变长，反而降低并发性能。聊天场景下100ms级别的落库延迟用户完全无感知，攒批带来的性能提升可以达到单条插入的5-10倍。

内容的提问来源于stack exchange，提问作者Tamer Awad