C++/MFC应用中SQLite构建慢及内存泄漏问题求助

核心PRAGMA参数调整 #

• 开启WAL模式：执行PRAGMA journal_mode = WAL;，WAL（Write-Ahead Logging）比默认的DELETE日志模式效率更高，写操作不会阻塞读请求，大幅降低磁盘I/O开销。
• 降低同步级别：执行PRAGMA synchronous = NORMAL;，默认的FULL级别会强制每次写入都刷盘，NORMAL级别仅在关键操作时刷盘，性能提升明显，且大部分场景下不会影响数据安全性；若能接受极端断电风险，也可设为OFF。
• 增大缓存：执行PRAGMA cache_size = -100000;（负数值代表KB，此处为100MB），让SQLite使用更大的内存缓存数据和索引，减少磁盘读写次数。
• 内存存储临时数据：执行PRAGMA temp_store = MEMORY;，让临时表、排序操作都在内存中完成，避免生成磁盘临时文件拖慢速度。
• 关闭自动索引：执行PRAGMA automatic_index = OFF;，防止SQLite为查询自动创建不必要的临时索引，减少插入时的索引维护开销。

操作逻辑优化 #

• 批量插入+单事务包裹：确保所有插入操作都放在一个事务中（不要每次插入单独开事务），检查是否存在事务提前提交的情况。另外，尽量用INSERT INTO table VALUES (...), (...), (...)的批量插入语法，减少SQL语句执行次数。
• 延迟创建索引：如果表需要创建多个索引，先完成所有数据插入，再创建索引。插入时维护索引会产生大量额外开销，先插数据后建索引的速度远快于边插边维护。
• 复用预处理语句：不要在函数F中每次执行INSERT/UPDATE都调用sqlite3_prepare16_v2，应该提前预处理一次语句，后续通过sqlite3_bind_*绑定参数，重复调用sqlite3_step执行，最后再调用sqlite3_finalize释放。这不仅能提升性能，还能解决部分内存泄漏问题。

针对sqlite3_prepare16_v2的泄漏排查 #

• 检查语句句柄释放：每次调用sqlite3_prepare16_v2成功后，必须对应调用sqlite3_finalize释放语句句柄。重点检查函数F中的分支逻辑（比如if/else、异常返回），是否存在某个分支下未执行sqlite3_finalize就返回的情况。
• Visual Studio断点定位：在Debug模式下，根据泄漏报告的分配序号（比如475），在程序初始化时添加_CrtSetBreakAlloc(475);，运行程序时会在分配该内存的代码处断点，查看调用栈就能定位到具体哪次sqlite3_prepare16_v2没有释放。
• 用RAII机制封装语句：编写轻量级封装类，在构造函数中调用sqlite3_prepare16_v2，析构函数中调用sqlite3_finalize，让语句句柄自动释放。示例：

class CSqliteStmt {
public:
    CSqliteStmt(sqlite3* db, const wchar_t* sql) {
        m_stmt = nullptr;
        sqlite3_prepare16_v2(db, sql, -1, &m_stmt, nullptr);
    }
    ~CSqliteStmt() {
        if (m_stmt) {
            sqlite3_finalize(m_stmt);
        }
    }
    sqlite3_stmt* GetStmt() { return m_stmt; }
private:
    sqlite3_stmt* m_stmt;
};

• 统计未释放语句数：调用sqlite3_db_status(db, SQLITE_DBSTATUS_STMT_COUNT, &current_count, &high_count, 0)，在函数F执行前后分别获取语句计数，如果计数持续增加，说明存在未释放的语句句柄。

内容的提问来源于stack exchange，提问作者Léa Massiot