mysql容器默认utc时区导致now()比北京时间慢8小时,须通过tz=asia/shanghai和mysql_time_zone='+08:00'双环境变量启动实现时区对齐,或挂载my.cnf配置default-time-zone并重启容器确保持久生效。

MySQL容器默认用UTC时区,NOW()比北京时间慢8小时——这不是MySQL“错”,而是它根本不知道该用哪个时区。必须在启动前或启动后明确告诉它东八区(+08:00 或 Asia/Shanghai),否则所有TIMESTAMP字段、日志、定时任务都会偏差。
docker run 时就设好 TZ 和 MYSQL_TIME_ZONE(推荐)
这是最干净的方式:不进容器、不改配置、不重启,从第一秒起就锁定时区。
-
TZ=Asia/Shanghai设置容器系统时区,影响date命令和system_time_zone -
MYSQL_TIME_ZONE='+08:00'仅对 MySQL 5.7+ 官方镜像生效,会自动写入配置并覆盖time_zone变量 - 两个环境变量必须同时加,缺一不可;只加
TZ不保证 MySQL 内部时区同步
完整命令示例:
docker run -d \ --name mysql-bj \ -e MYSQL_ROOT_PASSWORD=123456 \ -e TZ=Asia/Shanghai \ -e MYSQL_TIME_ZONE='+08:00' \ -p 3306:3306 \ -v /data/mysql:/var/lib/mysql \ mysql:8.0
验证命令:docker exec mysql-bj mysql -uroot -p123456 -e "SELECT NOW(), @@global.time_zone, @@global.system_time_zone",三者都应显示当前北京时间。
已运行的容器临时改时区(仅到下次重启)
适合测试或紧急修复,但容器重启后失效。本质是动态修改 MySQL 内部变量,不碰系统或配置文件。
在 Linux 上通过 Docker 运行 OpenClaw,并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 进入 MySQL:
docker exec -it mysql-bj mysql -uroot -p123456 - 执行:
SET GLOBAL time_zone = '+08:00';(影响新连接) - 再执行:
SET time_zone = '+08:00';(影响当前会话) -
FLUSH PRIVILEGES;不是必须,但部分旧版本要求
注意:SET GLOBAL 对已有连接无效,需重连才能看到 NOW() 变化;SYSDATE() 仍可能受 system_time_zone 影响,所以这个方式无法让四值完全一致。
挂载自定义 my.cnf 实现永久生效(生产首选)
适用于需要稳定、可复现、符合运维规范的场景。关键点:改的是 MySQL 的配置,不是容器系统时区。
- 确认配置路径:
docker exec mysql-bj ls /etc/mysql/mysql.conf.d/mysqld.cnf(MySQL 5.7+ 多用此路径) - 本地创建
timezone.cnf,内容为:[mysqld] default-time-zone='+08:00'
- 挂载时用
-v /path/to/timezone.cnf:/etc/mysql/conf.d/timezone.cnf,不要覆盖整个/etc/mysql/conf.d/ - 挂载后必须重启容器,否则不生效
这个方式能确保 @@global.time_zone、@@session.time_zone、system_time_zone、NOW() 四值长期一致,且不受容器重建影响。
别踩这些坑:TZ 挂载 /etc/localtime 不够用
有人试过 -v /etc/localtime:/etc/localtime:ro,发现 NOW() 还是 UTC——因为这只是改了系统时区,没动 MySQL 的 time_zone 变量。
-
TZ环境变量 +MYSQL_TIME_ZONE是官方镜像唯一支持的双保险组合 - 只挂
/etc/localtime不能改变system_time_zone在 MySQL 启动时的读取结果(部分镜像启动早于挂载) - Alpine 基础镜像不带
tzdata包,TZ环境变量可能被忽略,必须额外安装或换 Debian 基础镜像
真正要稳,就得让系统时区、MySQL 配置、MySQL 运行时变量三层全部对齐——少一层,TIMESTAMP 字段就可能悄悄出错。










