直接用 std::queue 管理连接会出问题，因为其不支持取出前验证连接有效性，失效连接（如网络断开、服务端 kill）会被直接返回，导致 execute() 抛异常或卡死；且 isClosed()/isValid() 仅反映本地状态，无法保证远端可达。
为什么直接用 std::queue 管理连接会出问题
连接池不是简单地把 mysqlcppconn 或 libpqxx 对象塞进队列就完事。真实场景下，连接可能因网络闪断、数据库重启、超时被服务端 kill 而 silently 失效——此时从队列取出来的对象调用 execute() 会直接抛异常或卡死，而不是自动重连。
关键点在于：连接对象本身不自带“心跳”和“状态自检”能力，必须在取出前验证可用性。
- 不要复用已关闭的
sql::Connection*（MySQL Connector/C++）或connection（libpqxx），它们的isClosed()/is_open()只反映本地状态，不保证远端可达 - 避免在归还连接时做完整健康检查（如发
PING），这会拖慢returnConnection()路径，影响吞吐 - 建议只在
getConnection()时做轻量探测：对 MySQL 用SELECT 1，对 PostgreSQL 用SELECT 1或pg_is_in_recovery()，超时设为500ms
如何设计线程安全且低开销的连接获取/释放逻辑
用 std::mutex + std::queue 在高并发下会成为瓶颈；而无锁队列又难保证连接对象生命周期安全。折中方案是分层控制：用 std::shared_mutex 保护空闲连接队列，但把连接对象本身交给 RAII 容器管理。
示例核心结构：
立即学习“C++免费学习笔记（深入）”；
class ConnectionPool {
mutable std::shared_mutex mtx_;
std::queue<std::shared_ptr<Connection>> idle_;
std::atomic<size_t> in_use_{0};
const size_t max_pool_size_;
// ... 其他字段
};
-
getConnection()：先尝试从idle_取，若为空且未达max_pool_size_，则新建连接并标记为 in_use；否则阻塞等待（用std::condition_variable配合超时） -
returnConnection(std::shared_ptr<connection> conn)</connection>：检查连接是否仍有效（仅用isValid()这类本地快速判断），再决定入队 or 丢弃 - 所有连接对象必须是
std::shared_ptr，确保归还时不会因析构触发同步操作
重连失败后怎么避免雪崩式重试
当数据库宕机，所有线程同时在 getConnection() 中尝试重建连接，会造成瞬时大量 TCP 握手和认证请求，进一步压垮恢复中的数据库。
必须引入退避机制：
- 首次重连失败后，延迟
100ms再试；第二次失败延300ms；第三次起固定为1s，上限不超过5s - 用
std::atomic<bool> is_db_down_</bool>做粗粒度熔断：连续 3 次getConnection()全部失败，则置true，后续请求直接返回错误，跳过重连逻辑 - 后台启动一个独立线程，每隔
2s尝试一次探活（发SELECT 1），成功后清空熔断标志
MySQL 和 PostgreSQL 的健康检查语句与兼容性差异
不能统一用 PING：MySQL Connector/C++ 的 ping() 是阻塞同步调用，libpqxx 没有等价接口；PostgreSQL 的 connection::is_open() 不检测网络层，需手动发查询。
- MySQL 推荐：
"SELECT 1"，配合setLoginTimeout(3)和setSocketTimeout(3000) - PostgreSQL 推荐：
"SELECT 1"，但需设置connection_base::options中的connect_timeout=3和keepalives=1 - 注意 libpqxx 7+ 默认禁用 keepalive，务必显式开启，否则连接可能在中间设备（如 NAT 网关）上被静默断开
- 如果用 MySQL Group Replication，健康检查应加
SELECT @@read_only避免往只读节点写入
mysql_real_connect() 成功返回，但下一次 mysql_ping() 却失败。这种边界情况必须靠应用层定时探测+熔断兜底，没有银弹。 
