std::thread并发更新数据库崩溃的根本原因是数据库连接对象不跨线程共享，必须为每个线程创建独立连接；推荐用std::async封装“单批次-单连接-批量执行”逻辑，并启用预处理语句提升性能。
std::thread 直接更新数据库会崩溃？
多数人第一次用 std::thread 并发执行 UPDATE 时，程序在第 2–3 个线程就 SIGSEGV 或抛出 SQLITE_BUSY/MySQL server has gone away。根本原因不是 SQL 写错了，而是底层数据库连接对象（如 sqlite3*、MYSQL*、或 ORM 的 session）**不跨线程共享**。
实操建议：
- 每个线程必须持有自己独立的数据库连接——不能把主线程创建的
sqlite3*或mysql_init()返回的句柄传给多个std::thread - 连接数要控制：开 100 个线程 + 100 个连接 ≠ 更快，可能触发 MySQL 的
max_connections限制或 SQLite 的 WAL 锁争用 - 使用连接池前先确认驱动是否线程安全：SQLite 编译时需定义
SQLITE_THREADSAFE=1（默认是），但若用的是预编译二进制，得查文档
用 std::async + lambda 封装单次批量更新更稳妥
std::async 比裸 std::thread 更适合封装“一个批次 → 一次连接 → 一批语句”的逻辑，它自动管理线程生命周期，避免忘记 join() 导致资源泄漏。
示例场景：把 10 万条记录按每批 500 条分组，并发更新
立即学习“C++免费学习笔记（深入）”；
std::vector<std::future<void>> futures;
for (size_t i = 0; i < data.size(); i += batch_size) {
auto batch = std::vector<Record>(data.begin() + i,
data.begin() + std::min(i + batch_size, data.size()));
futures.push_back(std::async(std::launch::async, [batch]() {
auto conn = create_new_mysql_connection(); // 每次都新连
mysql_query(conn, "START TRANSACTION");
for (const auto& r : batch) {
char sql[512];
snprintf(sql, sizeof(sql), "UPDATE t SET val=%d WHERE id=%d", r.val, r.id);
mysql_real_query(conn, sql, strlen(sql));
}
mysql_query(conn, "COMMIT");
mysql_close(conn);
}));
}
for (auto& f : futures) f.wait(); // 等全部完成
注意点：
- lambda 捕获要用值捕获（
[batch]），避免引用外部循环变量导致未定义行为 - MySQL 必须显式
START TRANSACTION+COMMIT，否则每条UPDATE都是独立事务，性能暴跌 - SQLite 若用 WAL 模式，多线程写入可并发，但仍需每个线程独立
sqlite3_open()
为什么不要用 std::jthread（C++20）直接管理 DB 连接
std::jthread 自动 join() 很方便，但它不解决连接归属问题。如果在线程函数里复用全局连接对象，崩溃照旧；如果在 jthread 构造时就把连接 move 进去，又容易因移动后原对象失效引发二次析构。
更实际的做法是：把连接创建和销毁完全限定在 lambda 作用域内，和线程生命周期对齐。例如：
- 错误写法：
std::jthread t([conn = std::move(global_conn)]{ ... });——global_conn可能被其他线程访问 - 正确写法：
std::jthread t([]{ auto conn = sqlite3_open_v2("db.db", ...); /* use */ sqlite3_close(conn); });
另外，std::jthread 的停止令牌（std::stop_token）对数据库操作基本无用：你无法安全中断一条正在执行的 UPDATE，强行 close 连接反而导致事务不完整。
批量更新卡在 IO 等待？检查 prepared statement 是否启用
不用预处理语句（prepared statement）的批量更新，每次都要经历 SQL 解析 → 编译 → 执行三步，CPU 和网络开销远大于实际写入。尤其 MySQL / PostgreSQL，开启 prepare 后性能常提升 3–5 倍。
关键操作：
- MySQL：调用
mysql_stmt_prepare()一次，然后循环mysql_stmt_bind_param()+mysql_stmt_execute() - SQLite：用
sqlite3_prepare_v2()编译一次，再用sqlite3_bind_*绑定参数，sqlite3_step()执行多次 - 切勿在循环内反复调用
prepare—— 这比不用 prepare 还慢
还要注意：某些 C++ 封装库（如 soci、SQLiteCpp）默认不启用 prepare，得手动调用 statement::prepare() 或传 soci::use 参数。
最易被忽略的一点：即使所有线程都用独立连接+prepare，如果表上存在未优化的索引（比如在 WHERE 字段没建索引），每个线程的 UPDATE 仍会扫全表，锁竞争和 IO 延迟会掩盖并行收益。上线前务必 EXPLAIN 每条批量语句。
