SQLite WAL模式插入耗时为普通/关闭日志模式4倍，预编译语句是否影响？

核心问题：重复预编译语句的额外开销 #

你的代码里，虽然prepare_statment函数逻辑上是要缓存预编译语句，但实际insert_nodes_to_table中每次循环都调用了sqlite3_prepare_v2——这意味着每次插入都在重复编译同一个SQL语句，哪怕缓存里已经存在可用的stmt。这种重复编译的CPU开销在WAL模式下被大幅放大，而OFF模式下因为日志机制简单，开销被掩盖，所以表现出WAL耗时远超OFF的情况。

为什么WAL模式下重复预编译的影响更大？ #

• OFF模式下，SQLite跳过了日志写入，磁盘IO操作极少，整体耗时主要由数据写入决定，重复编译的CPU开销占比低，所以对整体速度影响不明显。
• WAL模式下，SQLite需要维护WAL文件的内存结构、事务状态和锁机制，每次预编译都会触发这些结构的校验与同步。循环里高频的重复编译会把这些额外开销叠加，最终导致CPU占用剧增，整体耗时被拉到4倍之多。

修复方案 #

1. 确保预编译语句只执行一次 #

修改prepare_statment函数，让sqlite3_prepare_v2只在首次获取对应stmtid的语句时执行，后续直接复用缓存的stmt：

sqlite3_stmt* prepare_statment(int stmtid){
  // 1. 先在缓存中查找已存在的stmt
  sqlite3_stmt* stmt = find_stmt_in_cache(stmtid);
  if(stmt != NULL){
    return stmt;
  }
  // 2. 未找到时才编译并加入缓存
  const char* sql = get_sql_by_stmtid(stmtid); // 根据stmtid获取对应SQL语句
  int rc = sqlite3_prepare_v2(db_write, sql, -1, &stmt, NULL);
  if(rc != SQLITE_OK){
    // 处理编译错误逻辑
    return NULL;
  }
  add_stmt_to_cache(stmtid, stmt); // 将新stmt加入缓存
  return stmt;
}

同时，把insert_nodes_to_table里的sqlite3_prepare_v2调用移除，直接使用prepare_statment返回的stmt即可。

2. 保留现有事务与绑定逻辑 #

你已经用BEGIN TRANSACTION和END TRANSACTION包裹批量插入循环，这个逻辑是对的，能大幅减少磁盘IO次数。循环内的sqlite3_bind_*、sqlite3_step、sqlite3_reset、sqlite3_clear_bindings操作也没问题，继续保留即可。

3. 额外的WAL性能优化 #

• 调整WAL文件大小限制，避免过度膨胀：

  PRAGMA journal_size_limit = 100000000; -- 设置为100MB，按需调整
  

• 降低同步级别（WAL模式下默认是FULL，NORMAL能在保证数据安全的前提下减少同步开销）：

  PRAGMA synchronous = NORMAL;
  

预期效果 #

修复重复预编译的问题后，WAL模式的插入性能会显著提升，甚至超过OFF模式——因为WAL的追加式写入效率远高于OFF模式的直接修改数据文件，只要消除了不必要的CPU开销，WAL的性能优势就能正常体现。

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