swoole协程mysql连接池必须使用swoole\coroutine\mysql等协程安全客户端，不可复用mysqli/pdo因二者同步阻塞、不支持协程调度；连接须隔离持有、用后归还，避免泄漏与错乱。
为什么 Swoole 的协程 MySQL 连接不能直接复用
因为 mysqli 和 PDO 是同步阻塞扩展，底层不支持协程调度。即使你在 Swoole\Coroutine\MySQL 里用它们，实际仍是同步调用，会阻塞整个协程 —— 这不是连接池问题，是扩展选型错误。
正确做法是只用 Swoole\Coroutine\MySQL 或 Redis 协程客户端，它们的 connect()、query() 等方法天然可挂起，才能被连接池管理。
- 连接池里的每个连接必须是协程安全的，即：同一时刻只被一个协程持有，用完
->close()或归还到池中 - 别在
onReceive回调里 new 一堆Swoole\Coroutine\MySQL实例却不释放 —— 这等于没池，只是瞎开连接 - 注意
maxIdleTime配置：空闲超时的连接会被自动销毁，避免服务长连后端数据库断连却不知情
Redis 连接池里 get() 后忘了 put() 会发生什么
连接不会回收，池子里可用连接数持续减少，直到耗尽。下一次 get() 就会卡在 yield 上，协程挂起等待空闲连接 —— 表现为接口响应延迟陡增，甚至超时。
这不是 Redis 服务端问题，是客户端连接生命周期没管住。Swoole 的 Swoole\Coroutine\Pool 不会自动回收未归还的连接。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 务必在
try...finally块里写put()，哪怕命令报错也要归还 - 别依赖析构函数（
__destruct）：协程结束不等于对象立即销毁，GC 时机不可控 - 可以用
defer注册归还逻辑，但要注意 defer 是协程级的，且仅在协程结束时触发，不如显式put()可靠
Swoole\Coroutine\Pool 初始化时 min 和 max 设多少才合理
没有固定值，取决于你的并发量、单请求 DB/Redis 耗时、以及后端服务承载能力。设太高浪费内存和后端连接数；设太低导致频繁创建销毁连接，反而增加延迟。
一个可落地的估算方式：
假设平均 QPS 是 100，平均单次 Redis 操作耗时 5ms，那理论上最多同时活跃的协程约 100 × 0.005 = 0.5 个 —— 显然不合理，因为请求有波峰。更实用的是压测后看连接池的 stats() 返回值：
var_dump($pool->stats()); // 查看 'used' 最高值、'idle' 波动范围
- 观察压测期间
used峰值，设min为该值的 60%~70%，max为峰值 + 20% - MySQL 连接池的
max通常不应超过 MySQLmax_connections的 70%，留余量给后台任务或监控连接 - Redis 连接池的
min可设为 0（冷启动友好），但max建议不超过 Redismaxclients的 80%
协程连接池和传统「连接复用」混淆的典型错误
有人把 static $conn 或全局单例当成连接池，这是危险的。协程共享同一个变量，但 Swoole\Coroutine\MySQL 实例不是线程安全的，更不是协程安全的 —— 多个协程同时调用它的 query()，底层 fd 会乱，大概率报错 Connection reset by peer 或返回错乱数据。
- 协程池的本质是「连接实例隔离」：每个协程拿到的是独立的连接对象，不是共享一个对象反复
query() - 别在
onWorkerStart里 new 一个Redis客户端然后挂到$server->redis上供所有请求共用 —— 这不是池，是灾难 - 真正复用的是底层 TCP 连接（通过
reusePort或连接池内连接保活），而不是 PHP 对象复用
最常被忽略的一点：连接池本身不解决慢查询或大 key 问题。它只是让连接不成为瓶颈，真正的性能卡点往往在 SQL 写法、索引缺失、Redis 大 value 序列化上 —— 池配得再好，一条 SELECT * FROM huge_table ORDER BY created_at 还是会拖垮整个协程调度器。
