MySQL 8.4 连接池为何拿到旧会话变量：会话状态跟踪与初始化核对

线上用连接池碰到过一类特别耗时间排查的问题：不是MySQL直接报连接被拒绝，而是业务请求明明从池里拿到了标记为可用的连接，查出来的`sql_mode`、时区、字符集这些配置，居然是上一个请求遗留的旧值。这类问题的根因大多不是连接池本身的借还逻辑有bug，而是MySQL本身就把全局变量和单连接的会话变量分开维护：新连接刚建立的时候，会用当时的全局配置值初始化会话变量，可连接被复用还给池子之后，默认不会自动把这些会话变量重置回初始状态。

连接池为什么会把旧会话变量带回请求

MySQL 8.4 文档把系统变量分为 global 和 session 两个范围。客户端连接建立时，某些 session 变量会从当时的 global 值初始化；之后应用在这条连接上执行 SET SESSION，改变的只是当前会话。连接回到池里再次借出时，它仍然保留上一次请求留下的状态。

因此，下面这个现象并不矛盾：管理员已经把全局时区改成 +08:00，新连接读到新值，池里一条几小时前创建的连接却仍然是旧值。

SELECT
  CONNECTION_ID() AS connection_id,
  @@GLOBAL.time_zone AS global_time_zone,
  @@SESSION.time_zone AS session_time_zone,
  @@SESSION.sql_mode AS session_sql_mode,
  @@SESSION.character_set_connection AS connection_charset;

先看同一条连接里的 global/session 对照。不要只执行 SELECT @@time_zone，因为不写范围时通常得到的是当前会话值，恰好会把问题隐藏起来。

用三组值判断问题发生在服务器还是连接池

排查时把证据分成三组：服务器当前全局值、当前连接会话值、连接池自身记录的创建时间和借还次数。三组数据能把“配置没有生效”“连接创建太早”“业务在会话内改过值”区分开。

如果 global 已经正确而 session 仍旧，优先检查连接创建时间和初始化钩子。若新旧连接都不对，再检查配置文件、启动参数和当前实例是否就是业务实际访问的实例。

session_track_system_variables 能观察什么，不能替你做什么

session_track_system_variables 是一个逗号分隔的变量名列表。MySQL 默认跟踪时区、自动提交和部分字符集相关变量；当列表中的 session 变量被赋值时，服务器可以向支持会话状态跟踪的客户端通知变量名和值。

SET SESSION session_track_system_variables =
  'time_zone,autocommit,sql_mode,character_set_connection';

SET SESSION time_zone = '+08:00';
SELECT @@SESSION.time_zone;

这里有两个容易混淆的点。第一，跟踪列表不是“连接初始化脚本”，设置它不会把旧连接重置成全局值。第二，客户端是否读取并暴露状态通知，还取决于客户端驱动对 MySQL 会话状态跟踪能力的支持；仅在服务端设置列表，不能保证应用日志里自动出现变化。

连接池初始化和借出复核要分成两道门

只在创建连接时执行一次初始化 SQL，适合设置连接生命周期内不会被业务改变的基础值；但如果请求代码可能修改时区、自动提交、SQL 模式或字符集，归还连接前必须恢复，借出时也最好再次核对关键项。

-- 连接建立后或借出时的基础检查
SELECT @@SESSION.time_zone,
       @@SESSION.autocommit,
       @@SESSION.sql_mode,
       @@SESSION.character_set_connection;

-- 请求结束前恢复本次请求可能改动的值
SET SESSION time_zone = '+08:00';
SET SESSION autocommit = 1;

应用层可以把这组检查放进连接池的 health check 或 borrow hook。不要用“连接还活着”替代“会话状态正确”：前者只能证明网络和协议仍可用，后者才是请求语义的前置条件。

如果连接池支持 session reset，应先确认它到底重置哪些变量，再决定是否追加显式初始化。不同驱动的 reset 行为不一定覆盖业务自定义变量，生产环境要用一条会话做实测，而不是仅凭配置项名称推断。

全局变更后的验证顺序

假设运维执行了 SET GLOBAL time_zone = '+08:00'，可以按下面顺序验收：

1. 在管理连接上读取 @@GLOBAL.time_zone，确认变更作用于正确实例。
2. 新建一条不经过连接池的连接，读取 @@SESSION.time_zone，确认初始化值发生变化。
3. 从旧连接池借出一条连接，同时记录 CONNECTION_ID() 和会话值，确认旧连接是否仍带旧状态。
4. 执行一次借出初始化或 session reset，再次读取会话变量。
5. 连续借还同一条连接，分别在请求前后检查时区、自动提交和字符集，确认没有状态泄漏。

验证时不要只测“重启应用后正常”。重启会把池里的旧连接全部换掉，无法证明借还边界真的可靠。至少要保留一条旧连接，覆盖配置变更前创建、变更后借出和请求修改后归还三个状态。

常见问题：MySQL 会话变量的几个边界

修改 global 变量后，旧连接会自动同步吗？

不会。旧连接已有自己的 session 值，只有重新连接或由应用显式设置，才会得到新的会话状态。

session_track_system_variables 会自动重置连接吗？

不会。它用于跟踪指定变量的赋值通知，不承担连接池清理和状态恢复职责。

为什么同一个连接里 global 和 session 值不同？

global 表示实例当前范围的值，session 表示当前客户端连接正在使用的值；连接建立时间和连接内的显式设置都可能造成差异。

连接池只配置初始化 SQL 够不够？

如果请求不会改动相关变量，通常够用；只要存在请求级修改，就应在归还或再次借出时做恢复与复核。

上线前的会话状态检查清单

• 确认关键变量同时有 global 和 session 两种读取方式。
• 记录连接创建时间，覆盖配置变更前后的旧连接与新连接。
• 列出请求代码可能改动的 session 变量，并明确恢复位置。
• 确认驱动是否支持并读取 MySQL 会话状态跟踪通知。
• 用真实连接池连续借还，检查状态不会从上一个请求泄漏到下一个请求。

连接池复用的不是一条“干净的通道”，而是一整套仍然存在的 MySQL 会话状态。把 global、session 和池内生命周期放在同一张检查表里，再用旧连接回归一次，通常比反复重启应用更快找到根因。