MySQL C API 的 mysql_store_result 和 mysql_use_result 怎么选

在 MySQL C API 里，mysql_store_result() 和 mysql_use_result() 都用于读取查询返回的结果集，但它们对客户端内存和当前连接的占用方式完全不同：前者先把全部结果取到客户端，后者让客户端逐行取。选择时先看结果集大小，再看应用是否需要随机访问、统计总行数，以及每一行的处理是否足够快。

官方资料：https://dev.mysql.com/doc/c-api/8.4/en/c-api-basic-interface-usage.html

需要可回看、可计数、尽快释放连接时选 mysql_store_result()；结果集很大、只需顺序消费且能快速读完时才考虑 mysql_use_result()。后者没有读完全部行之前不能发起下一条查询。

先看两种结果集读取模型

调用 mysql_query() 或 mysql_real_query() 成功后，如果语句产生结果集，就需要用其中一个结果集函数接住它。两者后续都通过 mysql_fetch_row() 访问行，但数据到达客户端的时机不同。

这不是“一个新、一个旧”的关系，而是内存和连接占用之间的工程取舍。大多数普通查询用 mysql_store_result() 更容易维护；只有流式消费的边界很清楚时，才值得承担 mysql_use_result() 的约束。

mysql_store_result 为什么更适合需要随机访问的场景

mysql_store_result() 会读取查询的完整结果，并分配一个 MYSQL_RES 保存它。之后的 mysql_fetch_row() 访问的是已经在客户端的数据，因此可以重新定位行、读取总行数，也不会让服务端一直等待客户端处理每一行。

代价也很直接：结果集越大，客户端需要承担的内存越多。若查询可能返回数百万行，不能只因为代码写起来简单就默认使用它，应先限制列数、分页或收窄查询条件。

#include 

int read_with_store(MYSQL *conn) {
    MYSQL_RES *result = NULL;
    MYSQL_ROW row;
    unsigned long long row_count;

    /* store_result 一次取回完整结果，适合需要计数或回看行的场景。 */
    if (mysql_query(conn, "SELECT id, name FROM account ORDER BY id") != 0) {
        return 1; /* SQL 执行失败时由调用方读取 mysql_error。 */
    }
    result = mysql_store_result(conn);
    if (result == NULL) {
        return mysql_field_count(conn) == 0 ? 0 : 2;
    }

    row_count = mysql_num_rows(result); /* 结果已在客户端，可以直接统计。 */
    while ((row = mysql_fetch_row(result)) != NULL) {
        /* 这里可以按需重复读取，或配合定位接口访问其他行。 */
        (void)row;
    }
    mysql_free_result(result); /* 释放 MYSQL_RES，避免客户端内存持续占用。 */
    (void)row_count;
    return 0;
}

这里的 NULL 需要结合 mysql_field_count() 或错误函数判断：没有结果集的语句和读取失败都可能让结果指针为空，不能把两种情况混为一谈。

mysql_use_result 的省内存代价是连接一直被占用

mysql_use_result() 只初始化结果集读取，不会把所有行先保存到客户端。每次调用 mysql_fetch_row() 才继续从服务端读取，因此客户端内存压力小得多，适合把大结果集顺序写入文件、消息流或另一个处理管道的场景。

它把压力转移到了连接生命周期：当前结果集没有消费完之前，不能在同一连接上执行其他查询。若每行处理很慢，服务端会一直等待，甚至影响正在读取的表被其他线程更新。因此，mysql_use_result() 不是简单的“省内存优化开关”，而是对处理速度和连接占用作出的承诺。

int read_with_use(MYSQL *conn) {
    MYSQL_RES *result = NULL;
    MYSQL_ROW row;

    /* use_result 按行读取，适合顺序消费而非随机访问。 */
    if (mysql_query(conn, "SELECT id, payload FROM event_log ORDER BY id") != 0) {
        return 1; /* 查询失败时不要继续调用 fetch_row。 */
    }
    result = mysql_use_result(conn);
    if (result == NULL) {
        return 2; /* 读取初始化失败，错误信息仍由连接对象提供。 */
    }

    while ((row = mysql_fetch_row(result)) != NULL) {
        /* 当前行处理要短，不能在这里长时间等待或执行同一连接的新查询。 */
        consume_event(row);
    }
    mysql_free_result(result); /* 读到 NULL 后释放结果，连接才回到可复用状态。 */
    return 0;
}

这个示例假定 consume_event() 不会在当前连接上发起查询。使用流式结果时必须一直 fetch 到 NULL；中途找到目标也不能直接丢下未读行，否则下一条命令可能触发 Commands out of sync。

按四个问题做选择

可以把判断收敛成一句话：store 用客户端内存换连接自由度，use 用连接占用约束换较低的客户端内存。两者都要在使用完结果后调用 mysql_free_result()，而且不能把同一结果集的两种读取方式混用。

几个容易踩到的边界

• 空结果集不是错误。 mysql_store_result() 可以返回一个非空但没有行的结果对象，不能只用行指针判断查询是否成功。
• 结果指针为空要再判断。 可能是语句本来不返回行，也可能是读取失败；应结合 mysql_field_count()、mysql_errno() 和 mysql_error()。
• use_result 不能提前退出。 即使业务上已经找到目标，也要继续 fetch 剩余行，或关闭并放弃当前连接，不能直接复用它执行新 SQL。
• 通信缓冲仍有上限。 官方文档说明流式读取的通信缓冲可能增长到 max_allowed_packet，单行异常膨胀时仍需关注配置和数据形态。

因此，先确定结果集的规模和消费方式，再决定函数；不要先按“内存越少越好”做选择。对普通列表、报表和需要排序回看的结果，mysql_store_result() 通常更稳；对明确的顺序导出和快速消费管道，mysql_use_result() 才能体现价值。