MySQL 连接池为什么会拿到旧会话变量：SESSION 状态、复用边界与初始化校验

很多开发在对接 MySQL 连接池的时候都碰到过这类怪事：刚从池子里取出来的连接，查 time_zone 不是默认的 SYSTEM，sql_mode 也和全局配置对不上，甚至残留了前一个业务逻辑临时设置的会话级变量，排查半天找不到问题根源。这不是驱动的隐性缺陷，本质是连接池复用归还后的连接时，没有完整处理 SESSION 状态的边界，也没做足够的初始化校验才导致拿到旧的会话变量。

连接池拿到带旧会话变量的连接，核心原因是 SESSION 状态是和物理连接绑定的，不会随单次请求结束自动清空，复用逻辑没有做对应清理就直接把旧连接分配给新请求。

连接池里的 MySQL 连接不是一张用完就清空的纸。一个请求把 time_zone、sql_mode 或临时表状态改掉后，连接回到池中，下一次借到的仍可能是同一个会话。要避免“偶发拿到旧变量”，关键不是每个业务方法都补一条 SQL，而是把会话初始化和复用校验放在连接池边界。

把连接当作带状态的会话管理：借出时统一初始化，归还时按能力清理，业务查询前用关键变量做一次可观测校验。

为什么同一条查询会读出不同的 SESSION 值

MySQL 的会话变量保存在服务端连接对应的会话上下文里。连接池复用的是这条连接，不是“全新连接对象”。因此第一个请求执行 SET SESSION time_zone = '+08:00'，第二个请求就可能看到这个结果；如果应用把连接设置成 UTC，问题会反过来。

常见症状是：单元测试和线上结果不一致，某个租户的日期查询偶尔偏移，或者只有高并发时才出现 SQL 模式不同。先别急着改业务 SQL，先把连接 ID 和关键变量同时打出来。

先用最小查询确认状态确实来自连接复用

SELECT CONNECTION_ID() AS connection_id,
       @@SESSION.time_zone AS session_time_zone,
       @@SESSION.sql_mode AS session_sql_mode;

连续从连接池借两次连接，分别执行上面的查询。如果 connection_id 相同，而第二次仍带着第一次设置的变量，就能确认复用边界存在状态残留。把查询放进临时诊断日志即可，不要把完整连接串或用户数据写入日志。

借出连接时把初始化动作收口

池的借出回调应当先执行初始化，再把连接交给业务层。下面用伪代码表达调用顺序，函数名对应常见连接池的生命周期概念，重点是顺序而不是某个库的 API：

pool.borrow()
SET SESSION time_zone = '+00:00'
SET SESSION sql_mode = 'STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'
SELECT @@SESSION.time_zone, @@SESSION.sql_mode
业务查询

初始化 SQL 要固定、可审查，不能拼接用户输入。校验查询返回预期值后才进入业务查询；校验失败就把连接标记为不可复用并记录 CONNECTION_ID()，这样比让业务层带着脏状态继续跑更容易定位。

归还时清理，别把 RESET CONNECTION 当万能橡皮擦

归还策略取决于驱动是否支持重置连接，以及应用是否使用了临时表、用户变量、预处理语句或事务。能够安全重置时，可在归还阶段执行 RESET CONNECTION；不支持时至少要回滚未完成事务，并明确关闭或重建带有不可控状态的连接。

复用后的状态可以按下面这条链路理解：

连接归还
RESET CONNECTION
连接池复用
旧 SESSION

这里的“旧 SESSION”是风险分支，不是期望结果：如果重置失败却仍把连接放回池中，下一次借出就会重新暴露问题。连接池应把重置失败视为淘汰连接的信号。

三个容易漏掉的复用边界

事务没有回滚

业务代码返回连接前没有回滚，下一次请求可能继承未提交事务或锁等待。归还钩子至少要检查事务状态，异常路径也必须经过同一套清理逻辑。

sql_mode 只在启动时设置

只在应用启动时设置一次，不代表池中新建、重连或故障替换出来的每条连接都一致。初始化 SQL 应绑定连接创建或借出生命周期，并在重连后再次执行。

时区与应用时区各自默默转换

数据库会话时区、驱动时区和应用时区如果没有约定，日期字段很容易出现“存储正确、展示偏移”。先统一约定，再用固定时间值做跨层核对，避免只看自然语言日志。

上线前的复用验收

1. 借出一条连接，记录 CONNECTION_ID()、@@SESSION.time_zone 和 @@SESSION.sql_mode。
2. 主动修改一个会话变量后归还连接，再次借出并检查归还钩子是否恢复预期。
3. 模拟初始化失败或重置失败，确认连接被淘汰，而不是静默回池。
4. 在重连后重复检查变量，确认新连接不会跳过初始化。

只要把“借出—初始化—校验—业务—归还—清理”当成一个完整生命周期，连接池复用就不再是随机性问题，而是可以被日志和验收用例约束的状态管理问题。

相关问题

为什么连接池里的 connection_id 会变化

连接断开、超时或重置失败后，连接池会创建新连接，因此连接 ID 变化是正常现象；需要确认的是新连接是否重新执行了初始化。

每条 SQL 前都执行 SET SESSION 可以吗

可以作为临时诊断，但长期会增加往返和维护成本。更稳妥的做法是把固定状态放到连接生命周期，并对关键查询保留轻量校验。