1 前言

在當今互聯網高速發展的時代，高并發、大數據量的處理已成為各大企業應用的常態。作為 Java 開發者，我們常常面臨著如何提高數據庫操作效率的挑戰。MyBatis-Plus 作為一款優秀的 ORM 框架，為我們提供了簡潔高效的數據庫操作方式。然而，當涉及到大規模數據的批量插入時，即使使用了 saveBatch 方法，性能提升仍然有限。

本文將揭秘如何通過配置 rewriteBatchedStatements=true 和預先生成 ID 等優化策略，將 MyBatis-Plus 批量插入的性能提升 2000%，助力您的應用突破性能瓶頸！

2 背景：批量插入的性能挑戰

2.1 場景描述

在實際開發中，如考試系統、訂單處理、日志存儲等場景，經常需要批量插入大量數據。例如，在一個在線考試系統中，創建一份試卷需要插入多張表的數據：

• 試卷表（exam）：存儲試卷的基本信息。
• 題目表（question）：存儲題目信息。
• 選項表（option）：存儲題目下所有選項信息。

在保存試卷時，需要關聯保存試卷、題目以及題目選項，此時對于保存的性能就有較高的要求了。

2.2 性能瓶頸

• 逐條插入效率低：傳統的逐條插入模式效率欠佳，每次插入數據時都要與數據庫進行交互，從而產生較高的網絡開銷以及數據庫解析成本。
• 外鍵關系處理復雜：題目與選項之間存在外鍵關聯，這就需要在插入數據后獲取主鍵 ID，無疑增加了操作的復雜程度。
• 批量操作性能有限：使用默認的 saveBatch 方法，其性能提升并不顯著，難以滿足高并發、大數據量的實際需求。

3 初探 MyBatis-Plus 的 saveBatch 方法

3.1 saveBatch 方法簡介

在 MyBatis-Plus 中，saveBatch 方法是用于批量保存數據的方法。它能夠在單次操作中將多條數據同時插入數據庫，從而提高插入效率，減少數據庫連接次數，提升性能。

boolean saveBatch(Collection<T> entityList);
    boolean saveBatch(Collection<T> entityList, int batchSize);

• entityList：要插入的實體類集合。可以是任何實現了 Collection 接口的集合類型，如 List、Set 等。
• batchSize（可選）：指定每次批量插入的大小。默認情況下，MyBatis-Plus 會一次性插入所有數據。如果設置了 batchSize，則會按指定大小分批插入，避免一次性插入大量數據時出現性能問題或內存溢出。

3.2 常用場景

• 批量插入數據：當需要插入大量數據時，使用 saveBatch 可以顯著提高性能。
• 提高數據庫寫入效率：減少數據庫連接和插入的次數，有效提升性能。
• 處理大數據量時的內存優化：通過分批插入，避免一次性插入大量數據導致內存溢出。

3.3 默認實現的局限性

• 不支持多條 SQL 合并：在默認情況下，即便使用 saveBatch，也有可能是逐條發送 SQL 語句。這會導致生成的 SQL 更冗長、性能較低，尤其是在數據量較大時，執行效率會明顯下降，無法充分利用數據庫批量插入的特性。
• 性能提升有限：默認實現并未針對批量插入進行特殊優化。例如，它可能無法充分利用 JDBC 的批量操作特性，導致性能不如手動實現的批量插入邏輯。對于大批量插入，性能可能不理想。
• 主鍵生成方式局限性：如果實體類中主鍵是由數據庫自動生成（如自增主鍵），默認實現會多次與數據庫交互獲取主鍵值。這會增加額外的數據庫開銷。尤其是當數據量較大時，主鍵生成的額外查詢操作會顯著降低性能。
• 外鍵關系處理復雜：需要在插入數據后獲取主鍵 ID，這導致無法在批量插入時建立關聯關系，使得外鍵關系處理變得復雜。
• 缺乏靈活性：默認實現只能進行簡單的插入操作，不能處理條件性插入（如：插入前判斷是否已存在相同記錄）或插入沖突處理（如主鍵沖突時自動更新數據）。對需要動態邏輯的場景不適用。

4 深度解析 rewriteBatchedStatements=true 的作用

4.1 JDBC 批處理機制

JDBC 批處理機制是一種優化數據庫操作性能的技術，允許將多條 SQL 語句作為一個批次發送到數據庫服務器執行，從而減少客戶端與數據庫之間的交互次數，顯著提高性能。通常用于 批量插入、批量更新 和 批量刪除 等場景。具體的流程如下：

//創建 PreparedStatement 對象,用于定義批處理的 SQL 模板。
    PreparedStatement pstmt = conn.prepareStatement(sql);
    for (Data data : dataList) {
      // 多次調用 addBatch() 方法,每次調用都會將一條 SQL 加入批處理隊列。
      pstmt.addBatch();
    }
      //執行批處理,調用 executeBatch() 方法，批量發送 SQL 并執行。
      pstmt.executeBatch();

4.2 MySQL JDBC 驅動的默認行為對批處理的影響

• 未開啟重寫：在默認狀態下，MySQL JDBC 驅動會逐一條目地發送批處理中的 SQL 語句，未開啟重寫功能。
• 性能瓶頸：頻繁的網絡交互以及數據庫解析操作，使得批量操作的性能提升效果有限，形成了性能瓶頸。

4.3 rewriteBatchedStatements=true 的魔力

• 啟用批處理重寫：啟用批處理重寫功能后，驅動能夠將多條同類型的 SQL 語句進行合并，進而發送給數據庫執行。
• 減少網絡交互：一次發送多條 SQL，可有效降低網絡延遲，減少網絡交互次數。
• 提高執行效率：當所有數據都通過一條 SQL 插入時，MySQL 只需要解析一次 SQL，降低了解析和執行的開銷。
• 減少內存消耗：雖然批量操作時將數據合并到一條 SQL 中，理論上會增加內存使用（因為需要構建更大的 SQL 字符串），但相比多次單條插入的網絡延遲和處理開銷，整體的資源消耗和執行效率是更優的。

未開啟參數時的批處理 SQL：

INSERT INTO question (exam_id, content) VALUES (?, ?);
INSERT INTO question (exam_id, content) VALUES (?, ?);
INSERT INTO question (exam_id, content) VALUES (?, ?);

開啟參數后的批處理 SQL：

INSERT INTO question (exam_id, content) VALUES (?, ?), (?, ?), (?, ?);

5 預先生成 ID：解決外鍵關系的關鍵

5.1 問題分析

在插入題目和選項時，選項需要引用對應題目的主鍵 ID。如果等待題目插入后再獲取 ID，會導致無法進行批量操作，影響性能。所以，預先生成ID就成了我們解決問題的關鍵。

5.2 預先生成 ID 的解決方案

使用 zzidc（自研的 ID 生成器）：

• 全局唯一：生成的 ID 在全局范圍內唯一，避免了主鍵沖突。
• 本地生成：無需依賴數據庫生成，減少了數據庫交互。
• 支持批量生成：提升獲取分布式唯一ID的效率

5.3 應用實踐

5.3.1 引入 zzidc

<!--id生成器-->
        <dependency>
            <groupId>com.bj58.zhuanzhuan.idc</groupId>
            <artifactId>contract</artifactId>
            <version>${com.bj58.zhuanzhuan.idc.version}</version>
        </dependency>

5.3.2 具體的代碼業務執行邏輯

在構建題目和選項數據時，預先生成 ID，并在選項中引用對應的題目 ID：

public Boolean createExamPaper(HeroExamRequest<ExamPaperRequest> request) throws BusinessException{
          // 構建題目數據
          Question question = new Question();
          question.setId(questionId);
          question.setExamId(examId);
          // ...

          // 構建選項數據
          Option option = new Option();
          option.setQuestionId(questionId);
          // ...
    }

6 綜合優化實踐：性能提升 2000%

6.1 配置 rewriteBatchedStatements=true

6.1.1 修改數據庫連接配置

實現這個配置的方式很簡單，只需要在我們現有的數據庫連接后面直接加上就好。例如：jdbc:mysql://localhost:3306/db_name?rewriteBatchedStatements=true

6.1.2 注意事項

• 驅動版本：確保使用的 MySQL JDBC 驅動版本支持該參數（5.1.13 及以上）。
• 參數位置：如果有多個參數，用 & 符號連接。

6.2 完整代碼示例

@Service
public class ExamServiceImpl implements ExamService {

  @Autowired
  private ExamMapper examMapper;
  @Autowired
  private QuestionService questionService;
  @Autowired
  private OptionService optionService;

  private static final int BATCH_SIZE = 2000;

  @Override
  @Transactional(rollbackFor = Exception.class)
  public void createExam(Exam exam, int questionCount, int optionCountPerQuestion) {
        // 預先生成試卷 ID
        long examId = zzidc.nextId();
        exam.setId(examId);
        examMapper.insert(exam);

        List<Question> questionList = new ArrayList<>();
        List<Option> allOptionList = new ArrayList<>();

        for (int i = 0; i < questionCount; i++) {
          // 預先生成題目 ID
          long questionId = zzidc.nextId();
          Question question = new Question();
          question.setId(questionId);
          question.setExamId(examId);
          question.setContent("題目內容" + i);
          questionList.add(question);

          // 構建選項數據
          for (int j = 0; j < optionCountPerQuestion; j++) {
            Option option = new Option();
            option.setQuestionId(questionId);
            option.setContent("選項內容" + j);
            allOptionList.add(option);
          }
      }

      // 批量插入題目和選項
      questionService.saveBatch(questionList, BATCH_SIZE);
      optionService.saveBatch(allOptionList, BATCH_SIZE);
  }
}

注意：以上代碼為示例，需根據實際項目進行調整。

6.3 性能測試

6.3.1 測試數據

• 數據量：總共插入 100 道題目，每道題目 3 個選項。

6.3.2 測試方案

• 未優化方案：逐條插入試卷、題目和選項數據。
• 使用 saveBatch：使用 saveBatch 批量插入，但未配置 rewriteBatchedStatements，且未預先生成 ID。
• 綜合優化方案：配置 rewriteBatchedStatements=true，預先生成 ID，使用 saveBatch 批量插入。

6.3.3 測試結果

說明：以上數據為多次測試的平均值。

6.3.4 數據分析

• 未優化方案：由于逐條插入，每次插入都需要與數據庫交互，導致耗時最長。
• 使用 saveBatch：減少了與數據庫的交互次數，性能有所提升，但未充分利用 JDBC 驅動的批處理優化。
• 綜合優化方案：通過配置 rewriteBatchedStatements=true，使 JDBC 驅動將多條 SQL 合并為一條，顯著減少網絡和數據庫開銷；同時預先生成 ID，解決了外鍵關系的問題，支持批量插入，最終實現了性能的大幅提升。

7 多線程并發插入的實現

7.1 問題分析

直接在多線程中調用 saveBatch 方法，可能導致以下問題：

• 程安全性：在 MyBatis 中，SqlSession 在默認情況下并非線程安全的。若在多線程環境下共享同一個 SqlSession，極有可能導致數據錯誤或引發異常。
• 事務管理：對于多線程操作而言，需要獨立的事務管理機制，以此來確保數據的一致性。
• 資源競爭：過多的并發線程有可能致使數據庫連接池被耗盡，進而降低性能。

7.2 正確的多線程實現方式

7.2.1 使用 @Async 異步方法

利用 Spring 的 @Async 注解，實現異步方法調用，每個異步方法都有自己的事務和 SqlSession。

配置異步支持：

@Configuration
@EnableAsync
public class AsyncConfig {
@Bean(name = "taskExecutor")
public Executor taskExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(4); // 核心線程數
    executor.setMaxPoolSize(8); // 最大線程數
    executor.setQueueCapacity(100); // 隊列容量
    executor.setThreadNamePrefix("AsyncExecutor-");
    executor.initialize();
    return executor;
  }
}

修改批量插入方法：

@Service
public class QuestionServiceImpl implements QuestionService {

  @Autowired
  private QuestionMapper questionMapper;

  @Override
  @Async("taskExecutor")
  @Transactional(rollbackFor = Exception.class)
  public CompletableFuture<Void> saveBatchAsync(List<Question> questionList) {
    saveBatch(questionList, BATCH_SIZE);
    return CompletableFuture.completedFuture(null);
  }
}

7.2.2 調用異步方法

public void createExam(Exam exam, int questionCount, int optionCountPerQuestion) {
  // ... 數據準備部分略 ...

  // 將題目列表拆分成多個批次
  List<List<Question>> questionBatches = Lists.partition(questionList, BATCH_SIZE);
  List<List<Option>> optionBatches = Lists.partition(allOptionList, BATCH_SIZE);

  List<CompletableFuture<Void>> futures = new ArrayList<>();

  // 異步批量插入題目
  for (List<Question> batch : questionBatches) {
    CompletableFuture<Void> future = questionService.saveBatchAsync(batch);
    futures.add(future);
  }

  // 異步批量插入選項
  for (List<Option> batch : optionBatches) {
    CompletableFuture<Void> future = optionService.saveBatchAsync(batch);
    futures.add(future);
  }

  // 等待所有異步任務完成
  CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
}

7.2.3 注意事項

• 線程安全：每個異步方法均擁有自身獨立的 SqlSession 和事務，從而有效地避免了線程安全方面的問題。
• 事務管理：在異步方法上添加 @Transactional 注解，能夠確保事務的獨立性。
• 異步結果處理：通過使用 CompletableFuture 來等待異步任務的完成，以此確保所有數據均已成功插入。

8 數據庫層面的優化

8.1 調整數據庫連接池

• 增加連接池大小：在多線程并發的情形下，務必確保數據庫連接池具備足夠數量的連接可供使用。
• 合理配置：應根據實際情況對連接池的最小連接數和最大連接數進行適當調整，以避免出現連接不足或者資源浪費的情況。

8.2 配置 MyBatis 的執行器類型

修改執行器類型為 BATCH：在 MyBatis 配置中，設置執行器類型，可以提高批量操作的性能。

<configuration>
  <settings>
    <setting name="defaultExecutorType" value="BATCH"/>
  </settings>
</configuration>

注意：使用 BATCH 執行器時，需要手動調用 sqlSession.flushStatements()，并處理返回的 BatchResult，復雜度較高，建議謹慎使用。

9 監控與調優

9.1 監控異步任務的執行情況

• 使用 CompletableFuture：在調用異步方法時，返回 CompletableFuture，可以方便地等待所有任務完成。
• 日志記錄：在異步方法中添加日志，記錄開始和結束時間，監控執行情況。

@Async("taskExecutor")
@Transactional(rollbackFor = Exception.class)
public CompletableFuture<Void> saveBatchAsync(List<Question> questionList) {
  long startTime = System.currentTimeMillis();
  saveBatch(questionList, BATCH_SIZE);
  long endTime = System.currentTimeMillis();
  logger.info("Inserted batch of {} questions in {} ms", questionList.size(), (endTime - startTime));
  return CompletableFuture.completedFuture(null);
}

9.2 調整線程池參數

• 線程池大小：依據服務器的 CPU 核心數以及數據庫的承載能力，對線程池的 corePoolSize 和 maxPoolSize 進行合理設置。
• 隊列容量：設置線程池的 queueCapacity，以防止因任務過多而導致內存溢出的情況發生。

10 最佳實踐總結

10.1 綜合優化策略

• 將 rewriteBatchedStatements 配置為 true：以此啟用 JDBC 驅動的批處理重寫功能，可顯著提高批量插入的性能表現。
• 預先生成 ID：采用 zzidc 等方式預先生成主鍵 ID，有效解決外鍵關系問題，進而支持批量插入操作。
• 使用異步方法進行多線程批量插入：運用異步方法來進行多線程批量插入，確保線程安全與事務獨立，避免出現資源競爭的情況。
• 調整數據庫連接池和線程池參數：對數據庫連接池和線程池的參數進行調整，以滿足多線程并發操作的實際需求。
• 監控異步任務和數據庫性能：對異步任務和數據庫性能進行實時監控，以便能夠及時發現并解決性能瓶頸問題。

10.2 注意事項

• 線程安全性：在多線程的環境之中，務必確保所有資源要么是線程安全的，要么是線程獨立的。
• 事務一致性：每個異步任務均擁有自身的事務，以此確保數據的一致性。
• 資源合理利用：避免因過多的并發線程而致使系統資源被耗盡，進而影響整體性能表現。

結語

深入理解 rewriteBatchedStatements=true 參數的效用，再結合預先生成 ID、恰當的多線程實現方式以及數據庫參數調整等優化策略，我們成功地將 MyBatis-Plus 批量插入的性能大幅提升了 2000%。這些優化技巧不但在考試系統中適用，在其他需要批量處理大量數據的場景下同樣具有重要的參考價值。

性能優化乃是一項系統性工程，需從應用層、數據庫層、硬件層等多個層面著手。期望本文的分享能夠在實際項目中為您提供切實可行的指導，助力您的應用成功突破性能瓶頸。

關于作者

張守法 俠客匯Java開發工程師