mysql连接最大生命周期由客户端驱动或连接池控制，服务端仅通过wait_timeout和interactive_timeout管理空闲连接；hikaricp用maxlifetime（建议比wait_timeout小30秒），sqlalchemy用pool_recycle+pool_pre_ping。
MySQL 连接最大生命周期由谁控制？
不是 MySQL 服务端直接管的，而是客户端驱动（比如 mysql-connector-java、pymysql、mysql2）或连接池（如 HikariCP、DBCP2）在应用层决定的。MySQL 服务端只通过 wait_timeout 和 interactive_timeout 控制空闲连接的自动断开，不强制回收“活跃但老”的连接。
常见误解是调大 wait_timeout 就能延长连接寿命——其实它只对“没发任何语句”的连接生效；一旦连接持续执行查询或保持事务打开，这个超时就一直不触发。
Java 应用中怎么设置连接最大存活时间？
如果你用的是 HikariCP（主流 Spring Boot 默认），关键配置是 maxLifetime，单位毫秒。它表示连接从创建起最多活多久，到期后连接池会主动关闭并新建连接。
-
maxLifetime默认值是 1800000（30 分钟），设为 0 表示永不过期（不推荐） - 建议设为比 MySQL 的
wait_timeout小至少 30 秒，例如 MySQL 设了 600（10 分钟），这里设540000 - 必须确保
maxLifetime≤wait_timeout，否则连接池可能试图复用一个已被 MySQL 关闭的连接，抛出Communications link failure或Connection reset
示例（application.yml）：
spring:
datasource:
hikari:
max-lifetime: 540000
Python pymysql 怎么避免长连接失效？
pymysql 本身不带连接池，也不自动检测连接有效性，所以“最大生命周期”得靠你自己控制：要么手动定期重连，要么套一层连接池（如 DBUtils.PooledDB），或者用 SQLAlchemy 的 pool_pre_ping=True + pool_recycle。
-
pool_recycle是 SQLAlchemy 的参数，单位秒，效果类似 HikariCP 的maxLifetime -
pool_pre_ping=True会让每次取连接前先发个SELECT 1探活，代价小但能避开大部分已断连 - 别依赖
autocommit=True来“保活”，它只影响事务行为，不影响连接状态
示例（SQLAlchemy 创建引擎）：
create_engine(
"mysql+pymysql://u:p@h/d",
pool_recycle=540,
pool_pre_ping=True
)
为什么连接被强制回收后还报 “Lost connection to MySQL server”？
根本原因不是 MySQL 主动踢人，而是连接在传输中途断了（网络抖动、中间代理超时、防火墙 kill 空闲流），而客户端没及时感知。这时候即使设置了 maxLifetime 或 pool_recycle，也救不了正在使用的那条连接。
- MySQL 的
wait_timeout只在连接空闲时计时，一旦有数据包收发，计时器就重置 - 真正可靠的手段是：启用 TCP keepalive（Linux 默认 2 小时太长，需调短），并在客户端开启
tcp_keepalive类似选项（如pymysql的read_timeout/write_timeout） - HikariCP 的
keepaliveTime（默认 0，禁用）可以配合 MySQL 的wait_timeout做定期探活，但仅限空闲连接
最容易被忽略的一点：连接池的 maxLifetime 和数据库的 wait_timeout 必须协同，且都要小于基础设施（如 SLB、NAT 网关）的连接空闲超时阈值——后者往往只有 5～10 分钟，且你无法修改。
