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 字段就可能悄悄出错。
