MySQL 服务启动前必须确认系统时区已正确设置
MySQL 自身不管理时区偏移，完全依赖系统时区（
/etc/localtime）或显式配置的
default-time-zone。如果 Linux 系统时区是
UTC而业务要求使用
Asia/Shanghai，但 MySQL 没配，会导致
NOW()、
CURDATE()、日志时间戳全错，且无法通过 SQL 临时修正所有场景（如 InnoDB 表的隐式时间列默认值）。 先用
timedatectl status确认系统时区是否为
Asia/Shanghai；不是则运行
sudo timedatectl set-timezone Asia/Shanghai检查
/etc/localtime是否为指向
/usr/share/zoneinfo/Asia/Shanghai的软链接：
ls -l /etc/localtime重启
systemd-timesyncd或
chronyd服务确保系统时间已同步：
sudo systemctl restart chronyd && sudo chronyc tracking
my.cnf 中必须显式配置 default-time-zone
仅靠系统时区不够。MySQL 启动时读取
default-time-zone值初始化时区缓存，若未配置，会 fallback 到 SYSTEM（即系统时区），但某些版本或容器环境可能行为不稳定。更重要的是：该参数影响
TIMESTAMP类型字段的存储/读取逻辑——它始终转为 UTC 存储，查询时再按此参数转回本地时间。 在
[mysqld]段添加：
default-time-zone = '+08:00'（推荐用固定偏移，避免夏令时歧义） 不要写
default-time-zone = 'Asia/Shanghai'：MySQL 依赖
mysql.time_zone*表支持命名时区，需手动加载，且容易因表损坏或缺失导致启动失败 修改后必须重启 MySQL：
sudo systemctl restart mysql（Debian/Ubuntu）或
mariadb（CentOS/RHEL） 验证：连接后执行
SELECT @@global.time_zone, @@session.time_zone;，应返回
+08:00
避免 TIMESTAMP 与 DATETIME 混用引发的时区陷阱
TIMESTAMP自动转换时区，
DATETIME完全不转换——这是最常被忽略的底层差异。例如插入
'2024-01-01 12:00:00'到
TIMESTAMP字段，在 +08:00 时区下实际存为 UTC 时间
2024-01-01 04:00:00；而
DATETIME字段原样存入、原样返回。 新表设计优先用
DATETIME，除非明确需要跨时区自动归一化 若必须用
TIMESTAMP，确保应用层和数据库层时区一致，否则
WHERE ts > '2024-01-01'可能因会话时区不同产生意外结果 检查现有表：
SHOW CREATE TABLE your_table\G，确认关键时间字段类型及默认值（如
CURRENT_TIMESTAMP是否带
ON UPDATE）
容器或云环境需额外注意挂载与初始化顺序
Docker 或 Kubernetes 中，MySQL 容器若挂载了宿主机的
/etc/localtime，但未同步宿主机的 NTP 配置，或容器启动早于宿主机时间同步完成，会导致 MySQL 读到错误的初始时间。 在 Dockerfile 或 deployment.yaml 中显式设置环境变量：
MYSQL_TIME_ZONE=+08:00（部分镜像支持该变量自动注入 my.cnf） 避免仅挂载
/etc/localtime，应同时挂载
/etc/timezone（Debian 系）或确保容器内
timedatectl可用 在容器启动脚本中加入等待逻辑，例如：
until chronyc tracking | grep -q "System clock"; do sleep 1; done，再启动 mysqld MySQL 的时区问题从来不是单点配置能解决的，系统时钟、MySQL 参数、字段类型、容器环境四者必须对齐。最容易被跳过的环节是：改完
my.cnf后没重启服务，或者重启了但没验证
@@global.time_zone的实际值。
