企业官网建设流程全解析

看到“C/C++ 访问 MySQL”这个主题，我知道很多人脑子里跳出来的第一个问题就是：现在谁还用 C 写数据库访问？Java 有 JDBC、Python 有 PyMySQL、Go 有 database/sql，C 语言看起来像是在考古。但我这几年一直在做底层系统和高性能服务，越做越发现，直接用 C/C++ 接 MySQL 的 Connector/C 仍然是最踏实又接近数据库本质的一条路。尤其在嵌入式模块、网关服务、游戏服务器这些对延迟和依赖极敏感的场景里，一套 mysql.h 加 libmysqlclient 就能解决问题，不用虚拟机，不用跨语言桥接，编译出来就是一个纯二进制客户端。

这篇文章不是从零讲 MySQL 语法，而是围绕“用 C/C++ 开发数据库访问层”这条主线，把环境搭建、核心 API、完整 CRUD、事务处理、连接池设计，以及我实际踩过的一系列坑都串一遍。无论你是刚接触 C/C++ 的学生，还是工作中要接手底层数据模块的开发者，都可以直接拿后面的代码片段当参考，不用再去翻零散的文档。

1. 为什么选择 C/C++ 作为 MySQL 客户端

1.1 场景决定技术选型

先给结论：如果你做的只是一个普通管理系统，完全没必要用 C/C++ 直接连 MySQL，Python、Java 会舒服得多。但如果你正在做下面这几类系统，情况就完全不同了。

物联网采集网关，边缘节点资源受限，内存往往只有几十 MB 到几百 MB，塞一个 JVM 或者 Python 解释器成本太高；量化交易或者实时风控系统，每一次行情事件都要走数据库，调用链上多一层中间层就多几十微秒延迟；游戏服务器，很多核心逻辑本身就是 C++ 写的，数据库访问如果单独起一个进程做 RPC，多一次序列化和网络往返，压力一大就很容易成为瓶颈；还有一类嵌入式设备，甚至需要把数据库客户端直接编译进固件，只能依赖 C API。

在这些场景里，C/C++ 访问 MySQL 就不是“老古董”，而是唯一性价比合理的选项。直接用 Connector/C 链接 libmysqlclient，程序启动时加载动态库，运行时调用 mysql_* 系列函数完成交互，整个过程没有解释器开销，也没有跨语言封装层，你在内存布局、执行时机、错误处理上能控制的细节都比高级语言多得多。

1.2 不同接入方式的取舍

不少人在选型时会被一堆名词绕晕，其实接入 MySQL 的方式就那几条路。我把常见方案放在一起对比，你按项目情况挑就行。

我的个人建议是：C 项目直接用 Connector/C，C++ 项目如果规模变大，可以考虑 sqlpp11 这类偏现代的封装，但前提是你已经理解底层 API 的行为。否则出了问题，你连报错信息都看不懂，更别说优化性能。

有一点要提前说明：直接写 C API 和写高级语言驱动完全是两种体验。高级语言里你调用一个fetchall，框架把内存和类型都管理好了；C 里所有MYSQL_RES、MYSQL_ROW、MYSQL_BIND都是实实在在的结构体，你要自己控制它们的生命周期。这正是 C/C++ 访问数据库的“门槛”，也是后面几节要重点展开的地方。

1.3 编译级联动的思维转变

用 C/C++ 连 MySQL 还有一个容易忽略的维度：从代码到运行是“编译、链接、加载”三步，每一环都可能出问题。头文件找不到，是 include 路径没配好；函数符号链接不上，是库没指定或者平台不匹配；运行时提示找不到动态库，是 PATH 没设置或者 DLL 没放到正确位置。这些问题在高级语言里基本不存在，但在 C/C++ 开发里是家常便饭。

所以后面环境搭建部分我会写得特别细，尽量把 Windows 和 Linux 两条线的差异都覆盖到。这个过程也是理解 C/C++ 程序构建流程很好的入口，调通一次之后，你再去用 Visual Studio 或者 VS Code 写别的底层模块，心里就有底了。

2. 搭建环境：从零到第一个连接

这一节我按“服务端、客户端库、IDE 配置、验证代码”四个步骤来，每一步都标记了 Windows 和 Linux 的差异。这里也是知乎、博客和群聊里每天都会出现的重灾区，一个路径写错或者位数选错，可能浪费一整晚。

2.1 安装并初始化 MySQL 服务端

Windows 下我推荐下载 zip 绿色包而不是用安装向导，因为 zip 包更可控，卸载也干净。去 MySQL 官网下mysql-8.x-winx64.zip，解压到一个固定目录，比如C:\mysql。然后在该目录下手动创建my.ini，里面必须显式写好basedir和datadir，否则后续mysqld启动时会因为找不到数据目录而莫名其妙失败。

[mysqld] basedir=C:/mysql port=3306 datadir=C:/mysql/data character-set-server=utf8mb4 default-authentication-plugin=mysql_native_password

注意datadir这个目录不要自己去新建空文件夹，而是用命令初始化。管理员身份打开终端，进入 bin 目录执行：

mysqld --initialize-insecure

--initialize-insecure的含义是初始化数据目录并生成一个空密码的 root 账号，专门用于本地开发。如果这时候你看到 bin 目录下多了一个data文件夹，说明初始化成功。接着执行：

mysqld --console

这个命令会以前台方式启动 MySQL，终端里能看到启动日志。想要注册成 Windows 服务，可以执行mysqld --install，然后通过net start mysql或者sc start mysql启动。服务无法启动时，第一件事不是重装，而是打开data目录下以.err结尾的日志文件，看里面最后几行报错。

Linux 下就简单得多，Ubuntu 系执行sudo apt install mysql-server，CentOS/RHEL 系执行sudo yum install mysql-server。装完后用systemctl start mysqld启动，再用grep 'temporary password' /var/log/mysqld.log去找初始随机密码。CentOS 系第一次登录必须改密码，这个步骤很多人会卡住，其实执行ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPassword';即可。

2.2 安装客户端开发库：很多人漏掉的一步

服务端装好了，接下来才是重点：客户端开发库。很多人只装了 MySQL 服务端就去找mysql.h，当然找不到头文件，因为服务端和开发库是两套东西。

Windows 下要额外下载 MySQL Connector/C 的 zip 包，解压后你会看到include和lib两个目录。include里放的是mysql.h以及一堆头文件，lib里放的是libmysql.lib和libmysql.dll。选择版本时注意 x64 和 x86 必须和你的编译目标一致，我曾经在同一台机器上因为 VS 默认编译 x86 而库是 x64，折腾了大半夜，全部报 LNK2019 找不到外部符号。

Linux 下开发包一般是独立的包名。Ubuntu 系执行：

sudo apt install libmysqlclient-dev

CentOS 系执行：

sudo yum install mysql-devel

装完后可以在系统目录里验证一下：

find /usr -name "mysql.h" 2>/dev/null ldconfig -p | grep mysql

如果能搜到libmysqlclient.so，说明客户端库已经就绪。Ubuntu 系如果找不到，可以再执行一次sudo apt search libmysqlclient，有时候包名会因为版本差异多一个数字后缀。

2.3 VS Code 与 Visual Studio 的编译环境配置

编辑器方面我不站队，VS Code 轻量，Visual Studio 在 Windows 下调试体验更完整，但核心配置逻辑是一样的：让编译器找到头文件，让链接器找到库文件。

VS Code 里我惯用的套路是这样：在c_cpp_properties.json的includePath中加入 Connector 的 include 目录，保证代码补全和语法检查能识别mysql.h。编译时不要用 VSCode 默认的 build 任务，而是自己写一个tasks.json，编译命令大概长这样：

gcc test.c -o test.exe -I"C:/mysql-connector/include" -L"C:/mysql-connector/lib" -lmysql

-I指定头文件目录，-L指定库目录，-lmysql告诉链接器要链接libmysql.lib。运行前把libmysql.dll复制到可执行文件同目录，或者把它的路径加入系统 PATH，否则启动时会直接给你报“找不到 libmysql.dll”。

Visual Studio 里的配置则是走项目属性面板：在“VC++ 目录”里设置“包含目录”和“库目录”，在“链接器 -> 输入 -> 附加依赖项”里填libmysql.lib。最容易踩的坑有三个：Debug 和 Release 用了不同配置却忘改；x86/x64 平台选错；以及忘记把libmysql.dll放到输出目录。前两个坑的典型表现是链接错误，第三个坑的典型表现是运行时报 0xc000007b 或者找不到入口点。

来看一个最小验证程序，它可以确认整个环境是否打通：

#include <stdio.h> #include <mysql.h> int main(void) { MYSQL *conn = mysql_init(NULL); if (conn == NULL) { fprintf(stderr, "mysql_init failed\n"); return 1; } if (mysql_real_connect(conn, "127.0.0.1", "root", "", NULL, 3306, NULL, 0) == NULL) { fprintf(stderr, "connect failed: %s\n", mysql_error(conn)); mysql_close(conn); return 1; } if (mysql_query(conn, "SELECT VERSION()") != 0) { fprintf(stderr, "query failed: %s\n", mysql_error(conn)); mysql_close(conn); return 1; } MYSQL_RES *res = mysql_store_result(conn); MYSQL_ROW row; while ((row = mysql_fetch_row(res)) != NULL) { printf("MySQL version: %s\n", row[0]); } mysql_free_result(res); mysql_close(conn); return 0; }

这里mysql_init(NULL)会分配一个新的连接对象；mysql_real_connect传入主机、账号、密码、库名和端口；mysql_query执行 SQL；mysql_store_result把查询结果取回内存；mysql_free_result释放结果集。如果程序能打印出 MySQL 版本号，说明从编译器到运行库的整条链路都通了。

3. 核心 API 链路解析

C API 的函数很多，但日常开发真正高频的就那么十几个。我做项目时习惯把它们分成四组：连接、查询、结果处理、错误处理。掌握了这条链路，你就能看懂百分之九十的 C/C++ 连接 MySQL 代码。

3.1 连接函数的每一个参数都别想当然

mysql_real_connect的签名很经典，但参数含义值得花点时间抠一下：

MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd, const char *db, unsigned int port, const char *unix_socket, unsigned long client_flag);

第一个参数mysql用mysql_init创建的连接句柄。host填127.0.0.1还是localhost有细微区别：localhost在 Unix 系系统上可能走 socket 文件而不走 TCP，Windows 上一般都会走 TCP。远程连接必须填 IP 或域名。port默认 3306，如果改了端口忘了填，客户端会一直连不上。

unix_socket参数在 Windows 上直接填NULL，Linux 上使用本地 socket 连接时可以填路径，比如/var/run/mysqld/mysqld.sock。最后一项client_flag平时填0就行，但有两个标志位很有用：CLIENT_MULTI_STATEMENTS允许多条 SQL 一次发送；CLIENT_FOUND_ROWS让受影响行数变成“匹配行数”，这对UPDATE语句做幂等判断很有帮助。

还有一个小细节：mysql_real_connect返回NULL表示连接失败，但函数会把错误信息写到连接对象里。所以打印错误时要带上句柄，否则可能看到空字符串。

3.2 查询与结果集：store_result 和 use_result 的区别

mysql_query只负责发送 SQL，并不负责取数据。执行完之后，你得用mysql_store_result或mysql_use_result来获取结果集。两者区别在于：

mysql_store_result会把客户端返回的所有数据一次性读取并缓存在内存中，之后mysql_fetch_row只是从这块内存里逐行取。好处是你mysql_close掉连接之后结果集还能继续用；坏处是结果集特别大时内存会瞬间飙升。

mysql_use_result则是边读边取，客户端每调用一次mysql_fetch_row才从服务器拉一行。内存占用小，但读取期间连接处于“被占用”状态，同一连接不能再执行其他查询，并且你必须取完所有行才能进行下一轮操作。

实际项目里，小结果集果断用store_result，大结果集或者长时间持有结果时用use_result。我曾经在一个导出功能里用store_result去读一张几十万行的表，程序内存直接涨到几个 GB，换成use_result后内存降了两个数量级，速度反而更快，因为省去了大批量拷贝的时间。

取列名也是个容易被忽略的操作。mysql_num_fields(res)返回列数，mysql_fetch_field(res)能拿到每列的name字段。很多新手写动态展示工具时拿不到列名，就是少了这两步。

3.3 错误处理：不能只看返回值

C API 里几乎所有函数都有返回值，但很多人拿到mysql_query的返回值后只判断是否为 0，出了问题全靠猜。正确的姿势是配合mysql_errno(conn)和mysql_error(conn)一起看：

if (mysql_query(conn, sql) != 0) { fprintf(stderr, "error %u: %s\n", mysql_errno(conn), mysql_error(conn)); return -1; }

mysql_errno返回的是 MySQL 错误码，这个码可以从mysqld_error.h里找到对应宏名称，方便代码里做分支判断。比如 1062 是唯一键冲突，1452 是外键约束失败。把错误码固化到日志里，比光靠描述字符串去猜要高效很多。

我自己的习惯是在项目里封装一个db_query函数，统一收口错误处理：出错时打印错误码、错误信息、当前 SQL 和执行时间，这样线上定位问题时有完整的上下文，不需要再去翻散落各处的调试代码。

3.4 预处理与事务：连接安全的最后拼图

mysql_query直接拼接 SQL 字符串在 C/C++ 里同样存在注入风险，而且字符串里如果包含单引号，一旦没转义就会引起 SQL 语法错误甚至数据错乱。解决方式是预处理语句，也就是常说的 prepared statement。

预处理的调用链是mysql_stmt_init、mysql_stmt_prepare、mysql_stmt_bind_param、mysql_stmt_execute、mysql_stmt_close。整个过程核心是MYSQL_BIND结构体，它把 C 语言的变量和 SQL 里的?占位符绑定在一起。这个机制我会在下一节用代码完整演示，这里先强调一点：MYSQL_BIND里的buffer_type字段决定了 MySQL 怎么解释你的内存数据，填错类型轻则数据错误，重则内存访问异常，这是 C/C++ 写数据库最容易踩的深坑之一。

事务的 API 也在这里提一下。默认情况下 MySQL 是自动提交，每一条 SQL 都会立即生效。需要事务时调用mysql_autocommit(conn, 0)关闭自动提交，执行完一组 SQL 后根据结果决定mysql_commit(conn)还是mysql_rollback(conn)。用完记得把自动提交恢复原样。

4. 完整实战：写一个可复用的数据库访问模块

理论说再多，不如直接看代码。这一节我按实际开发的流程走一遍，从建表开始，到封装连接，再到预处理写入和事务回滚，最后你会发现，所有操作都能归纳成一套稳定的模板。

4.1 设计一张简单的业务表

先建两张演示表，一张用户表users，一张账户表accounts，后者用来演示事务：

CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL, age INT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE accounts ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, balance DECIMAL(10,2) NOT NULL DEFAULT 0 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

utf8mb4字符集是必须的，它能完整支持中文和 emoji 字符。如果你用老的utf8，某些生僻字或特殊符号会变成问号甚至触发写入错误。

4.2 封装连接结构体

我推荐把所有数据库相关操作封装成一个模块，至少在工程里用一个结构体把连接对象和最近一次错误保存下来：

typedef struct db_conn { MYSQL *mysql; char last_error[512]; } db_conn; int db_init(db_conn *db, const char *host, const char *user, const char *passwd, const char *dbname, unsigned int port) { memset(db, 0, sizeof(*db)); db->mysql = mysql_init(NULL); if (db->mysql == NULL) { snprintf(db->last_error, sizeof(db->last_error), "mysql_init failed"); return -1; } if (mysql_real_connect(db->mysql, host, user, passwd, dbname, port, NULL, 0) == NULL) { snprintf(db->last_error, sizeof(db->last_error), "connect failed: %s", mysql_error(db->mysql)); mysql_close(db->mysql); db->mysql = NULL; return -1; } mysql_set_character_set(db->mysql, "utf8mb4"); return 0; } void db_close(db_conn *db) { if (db->mysql != NULL) { mysql_close(db->mysql); db->mysql = NULL; } }

这里我特意调用了mysql_set_character_set，它的作用是把客户端连接的字符集设置为utf8mb4。少了这一句，即使服务端字符集正确，传进去的中文也可能出现乱码或者长度限制问题。这个坑我在早期项目中踩过，排错排了半天，最后才发现是连接层没设置字符集。

4.3 增删改查：两种写法的对比

先看用mysql_query直接拼接的方式，适合固定 SQL 和内部工具，但强烈不建议用在面向用户的接口上：

int db_execute(db_conn *db, const char *sql) { if (mysql_query(db->mysql, sql) != 0) { snprintf(db->last_error, sizeof(db->last_error), "query failed: %s", mysql_error(db->mysql)); return -1; } return 0; } char sql[256]; snprintf(sql, sizeof(sql), "INSERT INTO users(name, age) VALUES('%s', %d)", name, age); db_execute(&db, sql);

如果name里有一个单引号，这条 SQL 就炸了，甚至可能被构造出恶意语句。所以生产环境必须走预处理语句：

int db_insert_user(db_conn *db, const char *name, int age) { const char *sql = "INSERT INTO users(name, age) VALUES(?, ?)"; MYSQL_STMT *stmt = mysql_stmt_init(db->mysql); if (stmt == NULL) return -1; if (mysql_stmt_prepare(stmt, sql, strlen(sql)) != 0) { snprintf(db->last_error, sizeof(db->last_error), "prepare failed: %s", mysql_stmt_error(stmt)); mysql_stmt_close(stmt); return -1; } MYSQL_BIND params[2]; memset(params, 0, sizeof(params)); unsigned long name_len = strlen(name); params[0].buffer_type = MYSQL_TYPE_STRING; params[0].buffer = (char *)name; params[0].buffer_length = name_len; params[0].length = &name_len; params[1].buffer_type = MYSQL_TYPE_LONG; params[1].buffer = &age; if (mysql_stmt_bind_param(stmt, params) != 0) { snprintf(db->last_error, sizeof(db->last_error), "bind failed: %s", mysql_stmt_error(stmt)); mysql_stmt_close(stmt); return -1; } if (mysql_stmt_execute(stmt) != 0) { snprintf(db->last_error, sizeof(db->last_error), "execute failed: %s", mysql_stmt_error(stmt)); mysql_stmt_close(stmt); return -1; } mysql_stmt_close(stmt); return 0; }

注意MYSQL_BIND初始化时必须先memset清零，否则结构体里的指针垃圾值会让库在绑定阶段读野地址。buffer_type为MYSQL_TYPE_STRING时，buffer_length是缓冲区大小，length指向实际字节长度；使用MYSQL_TYPE_LONG时，buffer指向int类型变量即可。这是 C API 数据绑定的核心规则。

查询操作类似，但要多处理结果集。我常用的是mysql_stmt_result_metadata获取结果列信息，然后用mysql_stmt_bind_result绑定输出缓冲区，再用mysql_stmt_fetch循环取行。这个流程写一次会了，后面所有查询都能套用。

4.4 事务示例：转账场景

事务是数据库开发的必修课。我用一个最简单的转账场景演示：给user_id为 1 的账户扣款 100，给user_id为 2 的账户加款 100。两条 SQL 必须同时成功，或者同时回滚。

mysql_autocommit(db.mysql, 0); const char *sql1 = "UPDATE accounts SET balance = balance - 100 WHERE user_id = 1"; const char *sql2 = "UPDATE accounts SET balance = balance + 100 WHERE user_id = 2"; if (mysql_query(db.mysql, sql1) != 0 || mysql_query(db.mysql, sql2) != 0) { fprintf(stderr, "exec failed: %s\n", mysql_error(db.mysql)); mysql_rollback(db.mysql); } else { mysql_commit(db.mysql); } mysql_autocommit(db.mysql, 1);

真实项目里还要检查这两个UPDATE语句实际影响的行数。如果扣款语句匹配了 0 行，说明账户不存在，也应该回滚。这里需要先获取my_ulonglong rows = mysql_affected_rows(db.mysql);，然后判断rows == 0时做回滚处理。

事务有一个常见误区：mysql_query返回 0 不代表 SQL 执行成功，它只代表 SQL 被成功发送并得到响应。比如更新语句在语法上正确，但匹配行数为 0，返回码仍然是 0。所以事务里必须结合行数判断一起做校验，不能只靠返回值。

5. 连接池：高并发下的必修课

5.1 为什么需要连接池

每创建一个 MySQL 连接，背后至少经历 TCP 握手、数据库鉴权、可能还有 SSL 握手和权限检查，这个过程在高并发场景下非常昂贵。如果你的服务每秒要处理上千次请求，每次都新建连接、用完关闭，性能损耗会直接吃掉业务逻辑的收益。

连接池的核心思想很简单：提前创建一批连接放在池子里，用完不销毁，归还给池子复用。这样真正付出连接开销的只有初始化阶段，运行时所有请求都从池中取现成连接，用完放回，延迟自然就下来了。

5.2 一个简化版连接池实现

生产级连接池要处理的东西很多，包括空闲超时、最大连接数、异常连接重建等。这里我用 C 语言写一个最简骨架，把核心机制展示清楚：借用、归还、等待。

#include <pthread.h> typedef struct conn_pool { MYSQL **array; int capacity; int count; int head; pthread_mutex_t lock; pthread_cond_t cond; } conn_pool; void pool_init(conn_pool *pool, MYSQL **conns, int capacity) { pool->array = conns; pool->capacity = capacity; pool->count = capacity; pool->head = 0; pthread_mutex_init(&pool->lock, NULL); pthread_cond_init(&pool->cond, NULL); } MYSQL *pool_acquire(conn_pool *pool) { pthread_mutex_lock(&pool->lock); while (pool->count == 0) { pthread_cond_wait(&pool->cond, &pool->lock); } MYSQL *conn = pool->array[pool->head]; pool->head = (pool->head + 1) % pool->capacity; pool->count--; pthread_mutex_unlock(&pool->lock); return conn; } void pool_release(conn_pool *pool, MYSQL *conn) { pthread_mutex_lock(&pool->lock); int tail = (pool->head + pool->count) % pool->capacity; pool->array[tail] = conn; pool->count++; pthread_cond_signal(&pool->cond); pthread_mutex_unlock(&pool->lock); }

思路用一个环形数组加信号量就能跑通。借用时从队首取，归还时放到队尾，队列空则阻塞等待。这里有几个细节值得关注：连接数组在初始化时就建好，后续不复用malloc，避免运行时内存碎片；每次借用归还都要加锁，防止多线程并发操作数组导致数据错乱。

这个版本只是骨架，生产环境还要加上空闲连接探测。比如一个连接被服务端因为wait_timeout主动关闭后，下一次借出时直接使用会报“MySQL server has gone away”。我的处理方式是在pool_acquire里先执行一次mysql_ping，如果返回非 0，就关闭旧连接、新建连接再返回给调用方。

5.3 线程与 MYSQL 对象的不兼容问题

这里要郑重重申一个 C API 的重要限制：MYSQL连接对象并不是线程安全的，同一个连接不能同时被多个线程使用。这和很多高级语言驱动的行为不一样，也是 C/C++ 程序员最容易踩的并发坑。

正确用法是“一个连接同一时间只属于一个线程”。线程 A 从池里借走连接 1，线程 B 从池里借走连接 2，各自用各自的连接，互不共享。线程结束归还前，确保没有未读取完的结果集和未提交的事务。

如果项目确实需要在一个线程内创建独立连接，并且在多线程程序里初始化客户端库，需要在每个线程中调用mysql_thread_init()。这个函数在不同平台上的行为有差异，好在大多数现代 MySQL Connector 已经自动处理了大部分场景，但手动调用一次可以避免旧版本平台库上的偶发崩溃。

6. 常见问题与排查技巧实录

到了分享踩坑实录的环节。下面这些问题我基本都在真实项目中遇到过，网上虽然能找到答案，但大多数比较零散。我把它们整理成速查表和备注，方便你直接对照。

6.1 高频问题速查表

6.2 容易忽略的五个隐蔽细节

第一个是mysql_library_init。Windows 平台上连接功能依赖 WSA 库的初始化，在 GUI 程序或者某些框架里，如果不调mysql_library_init，mysql_init可能会返回空指针。Linux 上大多数情况下可以省略，但为了跨平台稳定，我建议在程序入口显式调用一次，退出时调mysql_library_end。

第二个是结果集释放。mysql_store_result返回的MYSQL_RES必须用mysql_free_result释放，否则每执行一次查询就泄漏一批内存。内存泄漏在短生命周期的工具里看不出来，但在长期运行的守护进程里，几天后内存就会涨到吓人。

第三个是MYSQL_BIND的长度字段类型。length参数在 32 位平台和 64 位平台的行为可能不一致，绑定字符串时用unsigned long接收strlen的返回值，写代码时留意类型转换，不要想当然地赋给int。否则数据量大的时候可能出现截断。

第四个是自动重连问题。MySQL Connector/C 8.0 之后，自动重连默认是关闭的，即使设置了MYSQL_OPT_RECONNECT，在事务中间断线也不会自动帮你在正确状态重连。最稳妥的方案是在连接池层面自己做健康检查和重建，而不是把希望寄托在客户端自动重连上。

第五个是mysql_use_result与“连接占用”的组合使用。如果你在用一个连接做流式读取，中间又想执行另一条 SQL，MySQL 会明确报错。规范做法是读完所有行再释放连接，或者干脆用两个独立连接隔离业务。

6.3 实操总结与最后一个技巧

我在实际开发中的体会是，C/C++ 操作 MySQL 最大的风险从来不是 API 不会用，而是内存生命周期和连接生命周期管理不当。每次写完数据库代码，我都会习惯性检查四件事：有没有释放所有MYSQL_RES；有没有关闭所有MYSQL_STMT；有没有在函数返回前把所有MYSQL*归还给对应模块；有没有确保连接在错误路径上也得到处理。

最后分享一个小技巧：调试连接问题时，先不要急着怀疑代码，用官方命令行客户端mysql -h127.0.0.1 -P3306 -uroot -p先测一遍，如果能连通说明服务端和网络没问题，问题就缩小到客户端库或编译器配置。这一步能帮你节省大量排查时间。把 C/C++ 数据库访问当成一个“编译型系统来调试”，你很快就会建立起对这套开发的整体掌控力。