设置MySQL @@session.time_zone替代CONVERT_TZ的弊端有哪些？

问题背景 #

我们的数据库采用MySQL timestamp类型存储数据，服务需为分布在多时区的客户返回适配其本地时区的查询结果。当前方案是通过CONVERT_TZ函数将服务器时区转换为客户时区，但该操作重复繁琐，单查询中可能出现五六次调用，还容易在关键查询中遗漏。因此考虑利用MySQL特性：timestamp会自动转换为连接的time_zone变量对应时区，通过查询前设置会话时区、查询后恢复的方式简化操作，现针对该方案的风险与弊端进行分析。

核心弊端 #

• 连接池复用导致的时区污染：如果系统使用数据库连接池，连接会被多个请求复用。若某次请求设置时区后因异常（如超时、代码抛出错误）未执行恢复步骤，后续复用该连接的请求会直接继承错误时区，导致查询结果完全不符合预期。即便每次都严格执行恢复操作，也无法完全避免异常中断带来的隐患。
• 隐性依赖增加维护成本：所有涉及timestamp的查询都依赖会话时区的正确设置，属于隐性规则。新开发人员或跨团队协作时，很容易忽略这个前置条件，直接编写未适配时区的裸查询，引发时区错误。
• 事务内的逻辑冲突：若在事务中切换时区，事务内所有查询都会使用该时区；如果事务中存在依赖系统时区的操作，会直接导致逻辑混乱。此外，事务回滚不会重置会话时区，即便事务执行失败，时区修改也会保留。

跨会话/连接的影响 #

会话级变量@@session.time_zone是每个连接独立隔离的，不会直接影响其他会话的变量值。但在连接池场景下，连接被不同请求复用，相当于“旧会话的残留设置”被带到新请求中，这不属于跨会话影响，而是连接复用带来的设置污染问题。

竞态条件与错误继承风险 #

• 异常中断导致时区未恢复：设置时区后，若查询过程中发生网络中断、应用崩溃等异常，恢复时区的步骤无法执行，该连接放回连接池后，下一个请求会直接使用错误时区查询。
• 连接池极端场景下的竞争：虽然标准连接池不会让连接在未释放时被抢占，但极端情况下（如连接池实现存在bug、配置错误），某请求刚设置完时区尚未执行查询，连接就被其他请求抢走，会导致错误时区被复用。
• 多客户请求的时序错误：若在同一个连接中连续处理多个客户的请求，未及时切换时区，会将A客户的时区错误应用到B客户的查询中，直接返回错误的时间数据。

内容的提问来源于stack exchange，提问作者Andrew Eames