自己实现轻量级连接池比接入重型第三方库更可控、更少踩坑；因std::shared_ptr不验证连接有效性、无空闲超时、无最大连接数限制、无获取超时机制，故不可靠。
直接用现成的 C++ 数据库连接池库是可行的，但绝大多数项目最终会发现：自己实现一个轻量级连接池比强行接入重型第三方库更可控、更少踩坑。
为什么 std::queue + std::shared_ptr 不足以构成生产可用的连接池
很多人尝试用 std::queue<:shared_ptr>></:shared_ptr> 封装连接对象，结果在高并发下频繁出现超时或连接泄漏。根本原因在于：
-
std::shared_ptr只管理生命周期，不控制连接的「有效性」——连接可能已断开但指针仍非空 - 没有连接空闲时间限制，失效连接长期滞留池中，下次取出时直接报
MySQL server has gone away或connection reset by peer - 缺乏最大连接数硬限制，突发请求可能瞬间创建数百个连接，压垮数据库或触发
Too many connections - 没有连接获取超时机制，线程可能无限阻塞在
pop()上
推荐方案：基于 sqlite3/mysql-connector-c++ 的简易池骨架
以 MySQL 为例，使用官方 mysql-connector-c++（v8.0+）配合手动管理连接状态。关键不是“复用对象”，而是“复用 TCP 连接并验证其活性”：
- 每次从池中取出连接前，必须执行轻量级校验（如
SELECT 1或调用sql::Connection::isValid()） - 连接归还时，若校验失败或空闲超时（例如 > 60 秒），直接销毁而非放回池中
- 池内连接数始终维持在
min_size~max_size区间，新连接仅在需要且未达max_size时创建 - 所有操作必须加锁，但粒度要细——只锁队列操作，不锁整个 SQL 执行过程
核心结构示意（省略异常处理与日志）：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
立即学习“C++免费学习笔记（深入）”；
class ConnectionPool {
private:
std::queue<std::unique_ptr<sql::Connection>> idle_;
std::mutex mtx_;
size_t max_size_ = 20;
size_t cur_size_ = 0;
std::chrono::seconds idle_timeout_{60};
public:
std::unique_ptr<sql::Connection> acquire() {
std::lock_guard<std::mutex> lk(mtx_);
if (!idle_.empty()) {
auto conn = std::move(idle_.front());
idle_.pop();
if (!conn->isValid()) {
conn.reset(); // 丢弃失效连接
return createNewConnection();
}
return conn;
}
return cur_size_ < max_size_ ? createNewConnection() : nullptr;
}
void release(std::unique_ptr<sql::Connection> conn) {
if (!conn || !conn->isValid()) return;
std::lock_guard<std::mutex> lk(mtx_);
idle_.push(std::move(conn));
}
private:
std::unique_ptr<sql::Connection> createNewConnection() {
cur_size_++;
try {
return std::unique_ptr<sql::Connection>(
driver_->connect("tcp://127.0.0.1:3306", "user", "pass")
);
} catch (...) {
cur_size_--;
throw;
}
}
};
实际部署时最容易被忽略的三个点
很多团队花几天搭好池子，上线后性能反而下降，问题往往出在这些细节：
- MySQL 服务端的
wait_timeout默认是 28800 秒（8 小时），但客户端池的空闲回收策略如果设为 300 秒，就可能出现连接被服务端单方面关闭而池子还不知道的情况 —— 必须同步调整 MySQL 配置或启用autoReconnect=true（注意该参数在 v8.0+ 已废弃，改用RECONNECT选项） - 连接池对象必须是进程级单例，不能按请求新建；否则每个线程都持有一个池，等于没池
- 事务场景下，连接不能中途归还 —— 必须由业务层明确调用
release()，否则会出现「连接被其他线程复用，导致事务上下文错乱」
连接池本身不解决慢查询，也不绕过锁竞争。它只是把「建连/断连」这个昂贵操作摊平。真正卡住性能的，往往是没索引的 SELECT * 或未绑定参数的拼接 SQL —— 池子越快，这类问题暴露得越彻底。
