thinkphp连接池获取失败不自动重试，需手动封装指数退避逻辑：捕获connectionexception，最多重试5次，延迟从100ms起翻倍，用usleep避免粗粒度阻塞。
连接池获取失败时直接抛异常，不是自动重试
ThinkPHP 的 ConnectionPool（5.1+）本身不内置重试逻辑，调用 get() 失败就立刻抛出 ConnectionException，不会等、不会退避、更不会自动再试。这是设计使然——连接池只管“池子”，不负责“抢不到怎么办”。
所以你看到 max_attempts 或 retry_interval 这类配置，基本是自己加的封装层，或者第三方扩展，原生 TP 没这玩意儿。
- 真实场景：高并发下
get()返回null或抛ConnectionException: No available connection - 根本原因：池中连接全被占用 + 超过
wait_timeout（默认 3 秒）仍无释放 - 别指望改
max_idle_time或min_idle能解决获取失败问题——它们影响的是连接生命周期，不是获取行为
手动实现指数退避重试：封装 get() + sleep() + 倍增等待
最轻量、最可控的方式，是在业务代码里包一层带退避的 get() 调用。不侵入框架，也不依赖额外包，几行就能跑起来。
关键点：每次失败后等待时间翻倍（100ms → 200ms → 400ms…），设上限避免卡死；总尝试次数建议 ≤ 5，否则说明池子真不够用，该扩配了。
-
$attempts = 0和$max = 5必须显式控制，不然可能无限循环 - 等待用
usleep(1000 * $delay)（毫秒转微秒），别用sleep()，太粗粒度 - 捕获具体异常：
think\db\exception\ConnectionException，别 catch 所有 Exception
$pool = \think\facade\Db::getPool();
$delay = 100; // ms
for ($i = 0; $i get();
} catch (\think\db\exception\ConnectionException $e) {
if ($i === 4) throw $e;
usleep(1000 * $delay);
$delay *= 2;
}
}
为什么不用 Swoole 协程池的 retry 配置？
如果你用的是 Swoole + ThinkPHP（如 Hyperf 风格改造），可能会看到 retry_count 或 retry_interval 这类配置项。但注意：那是 Swoole 的 Coroutine\MySQL 或 ConnectionPool 自己的逻辑，和 ThinkPHP 的 ConnectionPool 无关。TP 的池子在协程环境下只是“借用”连接，不参与底层重试决策。
- TP 层拿到的已经是 Swoole 池返回的连接，Swoole 重试发生在连接建立阶段（比如 DNS 解析、TCP 握手），不是 TP 获取阶段
- 若你在 Swoole 池里开了重试，TP 层再套一层退避，容易叠加等待，响应时间不可控
- 验证方式：关掉 Swoole 的
retry_count，只留 TP 封装层，看错误日志是否还出现重试痕迹
连接池大小与重试策略必须匹配，否则重试没意义
指数退避再优雅，也救不了池子本身太小的问题。如果 max_active 设成 5，而并发请求恒定在 20，那重试只是把失败从“立刻报错”拖成“慢速报错”。
- 查当前负载：
Db::getPool()->getStats()返回used/idle/wait_count，重点关注wait_count是否持续上涨 - 临时缓解可调大
max_active和wait_timeout，但要同步观察 MySQL 的max_connections是否够用 - 真正稳定的做法：压测确定 QPS 峰值，按公式
max_active ≈ QPS × 平均 SQL 耗时（秒）× 1.5反推，再加 20% 余量
退避策略本质是买时间，不是解决问题。池子撑不住，再多的 sleep 也只是让错误来得更温柔一点。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
