MySQL连接池配置避坑指南：wait_timeout与interactive

MySQL连接池配置避坑指南：wait_timeout与interactive_timeout的隐藏关联

最近在排查一个线上服务偶发的数据库连接异常时，我发现了一个容易被忽略的“定时炸弹”。现象很典型：应用在低峰期运行平稳，但一到业务高峰期，日志里就会零星出现“Connection is closed”或“Communications link failure”的错误。团队最初怀疑是网络问题或数据库负载过高，但监控指标一切正常。经过一番深度排查，最终将问题锁定在了MySQL服务器的wait_timeout参数与应用层连接池的maxLifetime配置之间的微妙博弈上。这不仅仅是设置一个超时时间那么简单，它涉及到数据库服务器、连接池客户端以及不同运行环境（如Docker）下的多重联动，任何一个环节的疏忽都可能导致生产环境的不稳定。今天，我们就来彻底拆解这个陷阱，并给出可落地的解决方案。

1. 理解超时：MySQL服务器端的“耐心”与连接池的“寿命”

要解决问题，首先得理解问题背后的两个核心角色：MySQL服务器和你的应用连接池。它们各自管理着连接的生命周期，但标准并不统一。

MySQL服务器的“耐心” (wait_timeout & interactive_timeout)

在MySQL的世界里，它不会无限期地维持一个空闲的连接。wait_timeout参数定义了MySQL服务器在关闭一个非交互式连接前，允许其空闲的秒数。所谓非交互式连接，通常指的是通过JDBC、ODBC等驱动程序建立的连接，也就是我们后端应用最常见的连接方式。

与之对应的是interactive_timeout，它针对的是交互式客户端（如mysql命令行工具）的空闲连接。虽然这两个参数在概念上区分了客户端类型，但一个至关重要的细节是：当建立一个新连接时，会话级别的wait_timeout值会被设置为interactive_timeout和wait_timeout两者中较小的那个。这意味着，如果你的interactive_timeout设置得更小，它可能会意外地成为所有连接的实际超时标准。

注意：许多开发者只关注wait_timeout，却忽略了interactive_timeout，这常常是配置失效的根源。安全的做法是始终将这两个参数设置为相同的值。

你可以通过以下命令查看当前全局和会话级别的设置：

-- 查看所有超时相关变量
SHOW GLOBAL VARIABLES LIKE '%timeout%';
-- 特别关注这两个
SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
SHOW GLOBAL VARIABLES LIKE 'interactive_timeout';

在我的案例中，就曾发现生产环境的interactive_timeout是1800秒（30分钟），而wait_timeout是28800秒（8小时），导致实际生效的是更短的30分钟。

连接池的“寿命” (maxLifetime)