单条INSERT不加事务会慢得离谱，是因为SQLite默认为每条INSERT隐式开启并提交独立事务，强制每次执行都触发fsync()落盘，1000次写入即1000次磁盘同步，耗时达10–50秒；正确做法是用BEGIN/COMMIT显式包裹批量操作，并复用预编译语句。
为什么单条INSERT不加事务会慢得离谱
SQLite默认每个INSERT语句都自动开启并提交一个事务，这意味着每次写入都要经历一次磁盘fsync()。在机械硬盘或某些嵌入式存储上，一次fsync()可能耗时 10–50ms；写 1000 条，就是 10–50 秒。这不是 SQLite 慢，是它被你“逼着”反复落盘。
关键点在于：sqlite3_exec() 或 sqlite3_step() 执行单条带分号的 SQL，不会合并成一个事务——它就只是单条执行。
- 别用
sqlite3_exec("INSERT ...; INSERT ...;")试图“批量”，SQLite 会把它当三条独立语句处理 - 哪怕只写一条
INSERT，只要没显式事务包裹，它就是原子事务 - 用 WAL 模式也不能绕过这个机制：WAL 解决的是读写并发，不是单语句事务开销
正确开启事务的三步写法（C++ RAII 封装前必须懂）
事务控制靠的是 BEGIN / COMMIT / ROLLBACK 这三个关键字，不是 API 函数。它们必须作为独立语句执行，且必须在同一个 sqlite3* 连接上完成。
典型错误是：在不同连接、不同线程、甚至不同函数里分别调用 sqlite3_exec(db, "BEGIN") 和 sqlite3_exec(db, "COMMIT") —— SQLite 不认这种“跨调用事务”。
- 务必在同一个
sqlite3*上连续执行"BEGIN"→ 多次INSERT→"COMMIT" - 用
sqlite3_exec()执行"BEGIN"和"COMMIT"即可，不需要特殊函数 - 如果中间某条
INSERT报错（如约束冲突），必须手动ROLLBACK，否则连接会卡在“事务中”状态，后续操作全返回SQLITE_MISUSE - 推荐用 RAII 封装一个
TransactionGuard类，在构造时BEGIN，析构时自动COMMIT或ROLLBACK（基于异常是否抛出）
批量写入时预编译语句 + 事务的组合效果
光加事务还不够。如果每条 INSERT 都走 sqlite3_prepare_v2() → bind → step → reset → finalize，prepare 和 finalize 的开销依然可观。真正快的做法是复用 sqlite3_stmt*。
示例逻辑：
sqlite3_exec(db, "BEGIN", nullptr, nullptr, nullptr);
sqlite3_prepare_v2(db, "INSERT INTO logs(time, value) VALUES(?, ?)", -1, &stmt, nullptr);
for (const auto& item : batch) {
sqlite3_bind_int64(stmt, 1, item.time);
sqlite3_bind_double(stmt, 2, item.value);
sqlite3_step(stmt);
sqlite3_reset(stmt); // 清除绑定，准备下一次
}
sqlite3_finalize(stmt);
sqlite3_exec(db, "COMMIT", nullptr, nullptr, nullptr);
- 必须在
BEGIN后、COMMIT前 prepare，否则 WAL 模式下可能触发 checkpoint 干扰性能 -
sqlite3_reset()是必须的，不 reset 直接 bind 下一组值会导致SQLITE_MISUSE - 如果 batch 中有非法数据导致某次
step返回SQLITE_CONSTRAINT，应立即ROLLBACK并清理 stmt，否则后续 step 全失败
容易被忽略的 WAL 与 autocheckpoint 冲突
开了 WAL 模式后，事务提交时 SQLite 会检查 WAL 文件大小，超过 wal_autocheckpoint 页数就自动触发 checkpoint（把 WAL 内容刷回主数据库文件）。这个过程是阻塞的，而且可能发生在你最不想卡住的时候——比如正在高频写入。
默认 wal_autocheckpoint = 1000（约 4MB WAL 日志），对批量写入来说太激进。
- 写入前执行
PRAGMA wal_autocheckpoint = 5000（或更高），减少 checkpoint 频率 - 不要在事务中执行 PRAGMA，它必须在事务外设置
- checkpoint 本身不阻塞新写入，但会阻塞新读取（直到 checkpoint 完成），所以高读负载时仍需权衡
- 如果写完就关库，记得手动
PRAGMA wal_checkpoint(TRUNCATE)，否则下次打开 WAL 文件可能很大
BUSY 等待超时太短，或者 WAL 模式根本没生效——这些细节比写几行 BEGIN/COMMIT 更决定成败。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
