MySQL 8.0连接卡顿主因是serverTimezone配置错误触发驱动反复探测空时区表，需显式设serverTimezone=Asia/Shanghai并启用useTimezone=true，配合容器时区文件就位，方可消除5–15秒延迟。
MySQL 8.0 连接时延和时区无关，所谓“因时区不一致导致连接时延”是误判——真正卡住连接的，通常是 serverTimezone 配置错误触发的时区表加载失败或驱动反复探测行为。
为什么改了 time_zone 还卡在连接阶段？
MySQL 8.0+ 的 JDBC 驱动（mysql-connector-java 8.0+）在建立连接时，如果 serverTimezone 参数缺失、写错或无法解析，会尝试从 MySQL 服务端查询 time_zone 表来推断时区。但该表默认未加载，且驱动在超时前会重试多次，造成明显延迟（常表现为 5–15 秒卡顿）。
-
serverTimezone=GMT%2B8：部分驱动版本不识别 URL 编码后的 GMT 偏移，直接 fallback 到查表逻辑 -
serverTimezone=CST：IANA 时区数据库里没有CST这个标准名，驱动无法映射，转而查表 - 服务端
@@global.time_zone是SYSTEM，但系统没装 tzdata（如 Alpine 容器），SELECT CONVERT_TZ(...)类函数也报错，加剧探测失败
如何验证是不是时区表导致的连接卡顿？
在 MySQL 命令行执行：SELECT @@global.time_zone, @@session.time_zone; 看返回值；再执行：SELECT COUNT(*) FROM mysql.time_zone_name;。如果返回 0，说明时区表为空——这就是连接慢的直接诱因之一。
- 空时区表 ≠ 不能用，但驱动（尤其 8.0.22+）会更激进地探测，加重延迟
- 用
mysql_tzinfo_to_sql加载时区表虽可行，但 Alpine 等精简镜像通常没这个工具，也不推荐线上操作 - 最稳做法：绕过查表，让驱动根本不走这一步
必须加的 JDBC 连接参数组合
不是只加 serverTimezone 就够——要配合关闭自动探测，才能彻底消除时延。
- 显式指定 IANA 时区名：
serverTimezone=Asia/Shanghai（不能写CST或GMT+8） - 强制跳过服务端时区校验：
useTimezone=true&serverTimezone=Asia/Shanghai（useTimezone=true是开关，缺它无效） - Spring Boot 用户注意：
spring.datasource.url必须包含这两个参数，spring.jackson.time-zone对数据库层完全无影响 - 若仍卡顿，追加
allowPublicKeyRetrieval=true&useSSL=false排除其他握手干扰（仅限内网测试环境）
Docker / 容器环境特别容易踩的坑
容器启动时没挂载宿主机时区、基础镜像没 tzdata、MySQL 配置里写了 default-time-zone=Asia/Shanghai 却没生效——这些都会让驱动在连接初期陷入“猜时区”循环。
- Alpine 镜像务必安装 tzdata：
apk add --no-cache tzdata，否则Asia/Shanghai解析失败 - Debian/Ubuntu 镜像需确认：
ls /usr/share/zoneinfo/Asia/Shanghai存在 - Docker 启动时建议同时挂载时区文件：
-v /etc/timezone:/etc/timezone:ro -v /usr/share/zoneinfo:/usr/share/zoneinfo:ro - 配置文件中避免写
default-time-zone=SYSTEM，改用default-time-zone='+08:00'，不依赖系统
真正耗时的从来不是时区转换本身，而是驱动在连不上时区信息时的反复试探。只要 serverTimezone 写对、useTimezone=true 开启、容器时区文件就位，连接就会回到毫秒级——别被 NOW() 显示时间误导，先盯住连接日志里的“Connecting to...”那段耗时。
