主线程退出时程序崩溃，是因为 std::thread 对象析构前未调用 join() 或 detach()，触发 std::terminate() 强制终止；这是 c++ 标准强制要求，而非线程未完成所致。
std::thread 启动索引优化任务时，为什么主线程一退出程序就崩？
因为 std::thread 对象析构前未调用 join() 或 detach()，会触发 std::terminate()。这不是“线程没跑完”，而是 C++ 标准强制的异常终止。
- 每个负责索引优化的
std::thread必须显式管理生命周期：优先用join()（等任务完成），仅在真正需要后台长期运行且能确保资源安全时才用detach() - 避免局部
std::thread变量：函数返回前若忘记join()，极易崩溃；建议用std::vector<:thread></:thread>统一持有，并在作用域结束前遍历调用join() - 如果索引优化任务可能耗时极长（如扫描 TB 级表），应配合
std::atomic<bool></bool>提供外部中断信号，而非依赖线程强制终止（std::thread::interrupt()已被移除）
多个线程并发调用 SQLite 的 CREATE INDEX 为什么会报 database is locked？
SQLite 默认使用 serialized 模式，但写操作（包括建索引）仍需独占 EXCLUSIVE 锁。多线程同时执行 CREATE INDEX 本质是并发写，必然冲突。
- 不能靠加
std::mutex包裹 SQL 执行来解决——锁的是 C++ 代码，不是 SQLite 内部页锁；必须让建索引操作串行化，即同一时刻只允许一个线程执行CREATE INDEX - 推荐方案：用单个专用线程 + 阻塞队列（如
std::queue+std::mutex+std::condition_variable）接收索引优化请求，其他线程只投递任务，不直连数据库 - 若底层换为 PostgreSQL 或 MySQL，可利用其支持并发创建索引的特性（如 PostgreSQL 的
CONCURRENTLY），但需注意：该模式下不能在建索引期间对表做 DML，且无法在事务块内执行
如何让索引优化任务感知表数据变更并自动重试？
没有通用“自动感知”机制。所谓“自动优化”，实际是定期检查 + 条件触发，而非监听文件系统或 WAL 日志。
- 最轻量方式：在每次业务写入后（如
INSERT/UPDATE后），递增对应表的修改计数器（存在内存中或 Redis），由后台线程定时扫描计数器，超阈值则触发优化流程 - 避免轮询开销：用
std::chrono::steady_clock控制检查间隔，首次触发后重置计数器，防止重复提交相同任务 - 注意事务边界：计数器更新与业务 SQL 必须在同一个事务内提交，否则可能漏统计；若用异步消息（如 Kafka）解耦，需接受最终一致性，容忍短时间延迟
std::async(std::launch::async) 比 std::thread 更适合索引优化吗？
不一定。它简化了结果获取，但没解决核心并发瓶颈，反而容易掩盖资源失控问题。
-
std::async默认策略是std::launch::deferred | std::launch::async，若未显式指定std::launch::async，可能退化为同步调用，导致“以为并发实则串行” - 返回的
std::future若未调用get()或wait()，其析构会阻塞等待完成——这在后台任务中极易造成意外阻塞，比std::thread更难调试 - 真正关键不是启动方式，而是资源隔离：每个索引优化任务应使用独立数据库连接（SQLite 需
SQLITE_OPEN_FULLMUTEX，PostgreSQL 需单独PQconnectdb），避免连接句柄复用引发状态污染
并发数不是越多越好。超过磁盘 I/O 并发能力后，建索引反而变慢，且可能拖垮在线查询。先用 iostat -x 1 观察 %util 和 await，再决定线程池大小。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
