MySQL C++ Connector批量插入内存占用过高问题咨询

看起来你碰到的是高频率批量插入场景下的内存耗尽问题，结合你的代码和使用场景，咱们拆解下问题根源，再给出可行的修复方案：

问题分析 #

你的代码里存在两个核心问题，直接导致了内存持续上涨直至耗尽：

1. 未正确释放动态分配的对象 #

MySQL C++ Connector中，prepareStatement()返回的PreparedStatement对象是动态分配的——调用close()只是关闭该对象关联的数据库连接资源，但不会释放它占用的堆内存。你在循环里每次都创建新的stmt，却只执行close()不做delete，这些对象会一直留在内存里，循环几千次后必然导致内存暴涨。

虽然你释放了ResultSet，但也要确保所有动态创建的数据库对象都能被完整清理。

2. 没有真正实现批量插入逻辑 #

你当前的代码每次循环都执行executeUpdate()，本质还是单条插入的逻辑，完全没用到Connector/C++的批量插入API。这种方式不仅效率极低，还会频繁创建销毁PreparedStatement，进一步加剧内存和性能损耗。

修复方案 #

第一步：修复内存泄漏 #

确保所有动态分配的PreparedStatement、ResultSet在使用完后，先close()再delete；更稳妥的方式是用C++智能指针（比如std::unique_ptr）自动管理资源，避免手动释放遗漏。

示例：用智能指针替代手动管理

// 智能指针会在对象超出作用域时自动执行close和delete，无需手动操作
std::unique_ptr<sql::PreparedStatement> stmt(con->prepareStatement(queryBuilder));

如果坚持手动管理，务必在每个对象使用完后执行：

stmt->close();
delete stmt;
stmt = nullptr; // 避免悬空指针

第二步：实现真正的批量插入 #

把PreparedStatement的创建移到循环外部，复用同一个stmt，通过addBatch()和executeBatch()批量提交数据，大幅减少数据库交互次数和对象创建开销：

优化后的完整示例代码：

try {
    con->setAutoCommit(false); // 因为autoClose为false，直接开启事务
    const int BATCH_SIZE = 1000; // 每1000条提交一次，可根据服务器性能调整
    int batchCount = 0;

    // 只创建一次PreparedStatement，循环复用
    std::unique_ptr<sql::PreparedStatement> stmt(con->prepareStatement(queryBuilder));

    while (/* 你的循环条件，比如读取待插入数据的循环 */) {
        this->setPreparedStatements(insertData); // 设置当前行的参数
        stmt->addBatch(); // 将当前参数添加到批量队列
        batchCount++;

        // 达到批量阈值时提交事务
        if (batchCount >= BATCH_SIZE) {
            stmt->executeBatch();
            con->commit();
            batchCount = 0;
        }
    }

    // 处理剩余的不足BATCH_SIZE的数据
    if (batchCount > 0) {
        stmt->executeBatch();
        con->commit();
    }

    // 获取自增ID（注意：批量插入后325412返回的是最后一条插入记录的ID）
    if (getAutoGeneratedKey) {
        std::unique_ptr<sql::PreparedStatement> idStmt(con->prepareStatement("SELECT 325412"));
        std::unique_ptr<sql::ResultSet> rs(idStmt->executeQuery());
        if (rs->next()) {
            result = rs->getInt(1);
        }
    }

} catch (sql::SQLException& e) {
    // 异常时务必回滚事务，避免数据不一致
    con->rollback();
    // 其他异常处理逻辑，比如打印错误信息
}

额外优化建议 #

• 调整批量大小：BATCH_SIZE可以根据实际场景调整（比如2000或5000），找到性能和内存占用的平衡点。
• 升级Connector版本：如果使用的是较旧的Connector/C++版本，建议升级到最新稳定版，旧版本可能存在已知的内存泄漏bug。
• 内存泄漏检测：可以用valgrind等工具检测内存使用情况，确认修复效果。

内容的提问来源于stack exchange，提问作者tolgatanriverdi