C++如何将std::vector数据批量插入SQLite数据库

很多开发者在处理std::vector数据批量插入SQLite时，第一反应就是写个循环，一条一条执行INSERT。单条执行配合sqlite3_step，对万级数据量来说，性能直接掉一个数量级。根本原因在于，每次调用都触发了完整的语句编译、参数绑定、执行、清理流程，还得反复刷盘。这显然不是明智之举。

真正应该做的，是预编译一次语句，然后复用sqlite3_stmt*，在事务中批量提交。具体来说，先通过sqlite3_exec(db, "BEGIN", nullptr, nullptr, nullptr)手动开启事务——如果想避免写冲突，可以用BEGIN IMMEDIATE。接着，调用sqlite3_prepare_v2一次，拿到sqlite3_stmt*。然后对vector中的每个元素，依次执行sqlite3_bind_*、sqlite3_step、sqlite3_reset——注意，这里用的是sqlite3_reset，而不是sqlite3_clear_bindings，因为后者并不会重置执行状态。最后，用sqlite3_exec(db, "COMMIT", ...)提交事务。

绑定std::vector时，生命周期问题别踩坑

sqlite3_bind_text默认使用SQLITE_TRANSIENT，意味着SQLite会在sqlite3_step返回后立刻拷贝字符串内容。这对vector里临时std::string对象是安全的。但如果你自作聪明传了&v[i][0]或v[i].c_str()，又没保证v[i]在整个事务期间不被移动或销毁，程序随时可能崩溃。

更稳妥的做法是：只有字符串内存长期有效时（比如全局const char*），才显式传SQLITE_STATIC。其他情况一律用SQLITE_TRANSIENT，同时确保std::string对象在sqlite3_step完成前不会析构。代码示例如下：

for (size_t i = 0; i < data.size(); ++i) {
    sqlite3_bind_text(stmt, 1, data[i].c_str(), -1, SQLITE_TRANSIENT);
    sqlite3_step(stmt);
    sqlite3_reset(stmt);
}

二进制数据插入，sqlite3_bind_blob才是正解

千万别拿sqlite3_bind_text去处理std::vector。它会把uint8_t*当C字符串处理，遇到\0就截断了。直接reinterpret_cast(vec.data())传给sqlite3_bind_text，是新手常犯的错误。

正确姿势是这样的：

• 用sqlite3_bind_blob(stmt, idx, vec.data(), vec.size(), SQLITE_STATIC)。这里用SQLITE_STATIC是合理的，因为vec.data()的生命周期由std::vector管理，只要vec不被clear()或resize()，内存就一直有效。
• 如果vec是在循环内定义的局部变量，必须保证它在整个事务结束前不销毁。通常的做法是把vector移到函数外，或者用std::move传入——不过要记住，移动后的原对象不能再访问了。

sqlite3_step返回值检查，很多人写错了

不少人只检查返回值是不是SQLITE_OK，但sqlite3_step成功返回的其实是SQLITE_DONE（表示单行执行完毕），而不是SQLITE_OK。另外，SQLITE_BUSY表示锁冲突，需要重试，这不是致命错误。

常见错误写法：

if (sqlite3_step(stmt) != SQLITE_OK) { /* error */ }

这会让所有正常插入都被误判为错误。正确逻辑应该是这样：

int rc = sqlite3_step(stmt);
if (rc == SQLITE_DONE) {
    // 成功
} else if (rc == SQLITE_BUSY || rc == SQLITE_LOCKED) {
    // 等待后重试，或者改用 BEGIN IMMEDIATE 提前抢占锁
} else {
    // 真正出错，查 sqlite3_errmsg(db)
}

事务运行时间越长，锁等待的风险就越大。相比BEGIN，BEGIN IMMEDIATE能有效减少SQLITE_BUSY的发生概率，但代价是会阻塞其他写操作。需要根据实际并发场景权衡使用。