连接池“空了”或“连不上”主因是资源耗尽、配置错位或连接泄漏，而非代码错误；需检查MySQL参数、连接归还逻辑、池大小配置、task进程稳定性、连接有效性验证及swoole_table容量。
连接池“空了”或“连不上”，90%不是代码写错了，而是资源耗尽、配置错位或连接泄漏了。
为什么 get() 总是返回 null 或抛出 empty pool 异常
这不是连接池“坏了”，而是它根本没拿到可用连接。常见原因有三个：
-
mysql连接参数错误（比如密码错、库名不存在），导致初始化时全部创建失败，池里压根没放进去任何连接 - 连接被
get()拿走后，没调用put()归还——尤其在异常分支、协程提前退出、return或throw前漏掉归还逻辑 - 并发量突增，但池大小（如
minActive/maxActive）设得太小，所有连接都被占满且超时未释放
查法很简单：加一行日志，在每次 get() 后立刻打印 $pool->getStats()，重点关注 active 和 idle 数值。如果 active === maxActive 且 idle === 0，就是池被撑满了；如果 active === 0 且 idle === 0，说明连接根本没建起来。
task 进程反复崩溃导致整个连接池断连
这是高负载下典型的雪崩起点：一个 task 挂了，manager 拉起新进程，但旧任务积压瞬间涌来，新 task 又挂……最终所有 task 进程消失，池内连接全被释放。
- 根本诱因常是协程数失控：
max_coroutine未设限，默认 3k，而每个数据库操作都占一个协程，连接池资源又绑定在task进程生命周期内 - 必须限制
task_worker_num并配平worker_num，例如 8 核机器可设worker_num => 16、task_worker_num => 4，避免task成为瓶颈 - 关键补救：在
onTask中加try/catch+finally { $pool->put($conn) ?? null; }，哪怕协程异常退出，也要尽力归还连接
MySQL 连接中断（2006/2013 错误）为何让池“失联”
连接池不会自动重连失效连接。一旦某次查询返回 mysqli->errno === 2006（server has gone away）或 2013（lost connection），这个连接对象就废了，但池子还把它当“健康”资源继续分发。
- 不能只靠
ping()，因为mysqli::ping()在某些版本或网络条件下会静默失败 - 推荐做法：每次
get()后，先执行一句轻量查询（如SELECT 1），失败则close()并put(null)，强制丢弃该连接 - 更稳妥的是在连接创建时启用
MYSQLI_OPT_CONNECT_TIMEOUT和MYSQLI_OPT_READ_TIMEOUT，避免卡死协程
swoole_table 大小不足引发的连锁故障
很多项目把设备 ID、连接状态、连接池句柄等存在 swoole_table 里，但它初始化后无法扩容。一旦写满，set() 失败却无报错，后续逻辑拿不到上下文，间接导致连接无法归还、池逐渐枯竭。
- 别按当前设备数设大小，要预估未来 2–3 年峰值，留至少 30% 余量
- 启动时加校验：
if (!$table->set($key, $val)) { throw new RuntimeException("swoole_table full at init"); } - 注意
swoole_table的内存单位是字节，size参数填的是总容量，不是行数
最麻烦的从来不是单点故障，而是多个看似无关的配置（max_coroutine、task_worker_num、swoole_table size、连接池 maxActive）在高压下同时触达临界点——它们不报错，只悄悄互相拖垮。
