MySQL C++ 客户端库选哪个？官方 vs 第三方
直接说结论：
mysqlcppconn（即 MySQL Connector/C++）是目前最稳妥的官方选择，但要注意它已不再活跃维护；若项目需要长期支持、异步或现代 C++ 特性，
sqlpp11或
nanodbc更值得考虑。
常见误区是默认用
libmysqlclient（C API）+ 手写封装——它稳定、快，但需自己处理 RAII、异常、类型映射，容易写出内存泄漏或 SQL 注入漏洞。
mysqlcppconn基于
libmysqlclient，提供面向对象接口，支持预处理语句（
PreparedStatement），但只到 C++11，不支持 move 语义，且 8.0+ 新认证插件（如
caching_sha2_password）需手动编译启用 SSL 和链接 OpenSSL
sqlpp11是纯头文件库，编译期检查 SQL 结构，生成类型安全的查询，但学习曲线陡，对动态拼接 SQL 支持弱
nanodbc轻量、跨数据库（支持 MySQL/PostgreSQL/SQL Server），基于 ODBC，需系统装 MySQL ODBC 驱动（
mysql-connector-odbc），Windows 下较省心，Linux 需配
odbcinst.ini
mysqlcppconn 连接失败的典型错误和修复
最常卡在连接阶段，报错类似：
Could not connect to database: Unknown MySQL server host 'localhost' (11001)或
Authentication plugin 'caching_sha2_password' cannot be loaded。
根本原因不是代码写错，而是环境配置未对齐：
立即学习“C++免费学习笔记（深入）”；
确认 MySQL 服务监听地址：检查my.cnf中
bind-address是否为
127.0.0.1或
0.0.0.0，而非
localhost（部分系统会走 socket 而非 TCP） 用户认证插件不兼容：MySQL 8.0 默认用
caching_sha2_password，而旧版
mysqlcppconn（解决方法是创建用户时显式指定插件：
CREATE USER 'appuser'@'%' IDENTIFIED WITH mysql_native_password BY 'pass123';SSL 强制开启时未提供证书：若 MySQL 启用了
require_secure_transport=ON，必须在连接 URL 加
?ssl-mode=REQUIRED，并确保客户端能读取 CA 文件（通过
setOption设置
sql::mysql::cli::SSL_CA）
如何安全执行带参数的查询（防 SQL 注入）
绝不要用字符串拼接构造 SQL，哪怕参数来自内部枚举。正确做法是统一走
PreparedStatement。
mysqlcppconn的预处理接口看着像 JDBC，但有关键细节差异： 占位符只能用
?，不支持命名参数（如
:id或
@name） 参数索引从 1 开始，不是 0：
stmt->setInt(1, user_id);字符串参数必须用
setString，不能用
setInt强转，否则可能触发隐式转换导致索引失效或全表扫描 批量插入慎用
addBatch()：底层仍是一条条发包，大数据量时不如构建多值 INSERT 语句（
INSERT INTO t VALUES (?,?), (?,?)）
示例（安全插入）：
std::shared_ptr<sql::PreparedStatement> pstmt(conn->prepareStatement(
"INSERT INTO users (name, age) VALUES (?, ?)"));
pstmt->setString(1, "Alice");
pstmt->setInt(2, 30);
pstmt->executeUpdate();
事务控制与连接生命周期怎么管才不出错
最容易被忽略的是：连接对象（
sql::Connection）不是线程安全的，且事务状态绑定在连接上，不能跨连接提交。
典型翻车场景：把
Connection当单例全局共享，多个线程并发调用
commit()，结果事务互相覆盖或静默失败。 每个线程应独占一个
Connection实例，或使用连接池（如
sql::mysql::MySQL_ConnectionPool），但注意池中连接复用前必须
rollback()清理残留事务状态 显式开启事务：调用
conn->setAutoCommit(false)后，所有后续操作都在同一事务内，直到
commit()或
rollback()—— 千万别依赖析构自动回滚，C++ 没有可靠的 finally 语义 长时间空闲连接可能被 MySQL kill（由
wait_timeout控制），建议在
getConnection()后加简单 ping：
conn->isValid()或执行
SELECT 1
事务失败后，连接仍可重用，但必须先
rollback()再继续，否则下一条语句会报
Commands out of sync。
