MySQL 连接池怎么设置 wait_timeout：空闲连接回收与断线重连边界

线上接口偶尔报“连接已断开”，重试一次又恢复，最容易被误判成网络抖动。很多时候，真正先动手的是 MySQL 服务端的 wait_timeout：连接池把一条空闲会话留得太久，服务端已经回收它，应用下一次借出时才发现连接失效。

wait_timeout 只负责服务端回收非交互连接的空闲时长，不能单独解决连接池复用、健康检查和重试边界。稳妥的做法是先测出连接池的空闲行为，再让池的回收时间早于服务端，最后只对可安全重放的操作做一次重连。

先分清：是连接池空闲，还是 MySQL 主动回收

先不要把全局值直接改成很大的数字。MySQL 8.0 文档把 wait_timeout 定义为非交互连接在无活动状态下等待的秒数，默认是 28800；interactive_timeout 只影响使用交互连接选项的客户端。大多数 Web 服务连接池拿到的是非交互连接，因此排查入口通常是 wait_timeout。

现场调试时可以先在同一条连接上分别查看全局和会话级的取值：

SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
SHOW SESSION VARIABLES LIKE 'wait_timeout';
SELECT CONNECTION_ID(), NOW();

如果 global 已经是 1800，而池里旧连接的 session 仍是 28800，不用觉得查询结果对不上很奇怪。session 值在连接建立时初始化，改 global 只对后续新会话更有意义；现有连接是否被池淘汰，要看池自己的生命周期策略。

把三个时间点排成一条可验证的链路

连接池适配不是单参数调优问题，核心是理清楚三个时间点的先后约束关系：

推荐的关系是：池的空闲回收时间小于 wait_timeout，并且保留一段可观测的余量。例如服务端设置为 1800 秒，池可以在 1500 秒左右主动淘汰空闲连接。这里不是追求一个“标准数字”，而是避免清理任务的调度抖动、网络延迟和时钟误差把边界撞在一起。

调整 wait_timeout 时，global 和 session 要分开处理

临时验证配置效果时可以只改 global：

SET GLOBAL wait_timeout = 1800;
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';

这一步适合观察新建连接的行为，不代表线上全部连接已经采用 1800。要让配置重启后保留，应把值写入 MySQL 配置文件，再按发布窗口重启或使用团队现有的配置变更流程。修改后重新建立一条连接，复查 session 值；不要在生产库里通过批量改 session 的方式掩盖连接池没有淘汰旧连接的问题。

如果客户端使用了 CLIENT_INTERACTIVE，连接建立时的 session 初始化可能参考 interactive_timeout。这也是为什么只看一个变量名，不能解释所有客户端行为。

断线后能不能重连，取决于请求是否可重放

MySQL 文档把常见断线分成客户端无法发送请求的 CR_SERVER_GONE_ERROR，以及写入后没有拿到完整响应的 CR_SERVER_LOST。后者尤其不能看到错误就无脑重试：服务端可能已经执行了写操作，只是响应在网络中丢了。

实际操作里可以把重连边界整理成清晰的判断规则：

• 借出连接时发现失效：丢弃这条连接，重新建连后再执行业务查询。
• 只读、无副作用、明确未发送成功的查询：允许一次重连重试，并记录原因。
• 事务中的写入或扣库存：先确认事务状态或业务幂等键，不能仅凭异常文本重放。
• 连续出现断线：检查 MySQL 错误日志、连接数、代理空闲超时和网络设备，而不是继续增大 wait_timeout。

常见误区与上线前检查

最常见的误区有三个：把 interactive_timeout 当成 Web 连接池的主开关；改完 global 后以为旧连接已经更新；把“重连成功”当成“上一条写操作没有执行”。这三种判断都可能让故障从偶发变成难以复现。

上线前至少留一份基线：连接池空闲回收值、MySQL global/session 值、代理层空闲超时、借出校验开关、重试次数和幂等策略。压测时让连接空闲超过池阈值但不要直接打满数据库，观察连接数、错误码和重建连接数量是否符合预期。

相关问题

wait_timeout 越大越好吗？

wait_timeout 不是越大越好。值越大，服务端保留的空闲会话可能越久，连接数和资源占用也更难回收，应该结合连接池规模、业务请求间隔和代理超时设置综合调整。

只设置连接池的 idle timeout 可以吗？

把连接池空闲回收值设得比 MySQL wait_timeout 更小，可以降低撞上服务端回收的概率，但仍建议保留借出前校验。清理任务不是实时触发的，网络抖动也会让边界连接留到下一次借出才暴露问题。

出现 MySQL server has gone away 就重试吗？

断线之后要不要重试不能一概而论。只读查询通常可以设计一次安全重试；事务写操作必须先判断副作用和幂等状态之后再处理。

总结

把 wait_timeout 当成服务端最后一道空闲回收线，把连接池空闲回收和借出校验放在它之前，再把重连限制在可验证的请求边界内，连接断开问题才会从“偶尔重试一下”变成可观测、可回滚的生命周期管理。