MySQL本身不管理时钟同步,只信任系统时间;需确保NTP服务启用且偏移≤±50ms、my.cnf中配置default-time-zone='+08:00'并重启mysqld、TIMESTAMP字段会自动时区转换而DATETIME不会、客户端连接必须显式指定serverTimezone参数。
MySQL 本身不管理时钟同步,它只信任系统时间。所谓“配置 MySQL 时钟同步”,本质是确保系统时间准、MySQL 读得对、字段类型不埋雷——三者缺一不可。MySQL 的 NOW()、CURRENT_TIMESTAMP 全部来自系统时钟。如果系统时间漂移,MySQL 就跟着漂移,这不是 bug,是设计使然。
timedatectl status,确认输出中包含 System clock synchronized: yes 和 service: chronyd(或 systemd-timesyncd)chronyc tracking | grep "Offset" 或 timedatectl timesync-status | grep "offset",理想值在 ±50ms 内sudo systemctl enable --now chronyd(CentOS/RHEL)或 sudo systemctl enable --now systemd-timesyncd(Debian/Ubuntu)/etc/chrony.conf 或注入 chronyd 进程time_zone 是 SQL 层变量名,不能写进配置文件;写进去会导致 MySQL 启动失败或静默忽略。唯一合法的全局配置项是 default-time-zone。
default-time-zone = '+08:00' —— 固定偏移,不依赖系统时区表,无兼容性风险default-time-zone = 'Asia/Shanghai':除非你已手动执行过 mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql 并验证 SELECT COUNT(*) FROM mysql.time_zone_name; > 0[mysqld] 段下,保存后必须 systemctl restart mysqld;热重载(如 mysqladmin reload)完全不生效SELECT @@global.time_zone, @@session.time_zone; 应返回 +08:00,而非 SYSTEM
这是最容易被忽略的底层行为差异,直接导致“存进去就变时间”。
TIMESTAMP 存的是 UTC 时间:插入 '2024-01-01 12:00:00' 到 +08:00 时区的 TIMESTAMP 字段,实际存入的是 2024-01-01 04:00:00(UTC)DATETIME 原样存储、原样返回,完全不转换;适合记录“固定时刻”(如发布会开始时间)TIMESTAMP + STATEMENT 格式 binlog,主库 NOW() 写入的时间字面量,会被从库按自身 time_zone 解析,结果错位DATETIME;已有 TIMESTAMP 字段,务必保证应用层、连接池、MySQL 全局/会话时区三者严格一致即使服务端配对了,客户端驱动仍可能因未明确时区而 fallback 到 SYSTEM,触发 Server returns invalid timezone 错误。
?serverTimezone=Asia/Shanghai(推荐)或 ?serverTimezone=GMT%2B8
useTimezone=true 不够,它只是开启转换逻辑,没指定具体时区照样报错serverTimezone=Asia/Shanghai,需确保 MySQL 已加载时区表(否则驱动无法解析,仍失败)default-time-zone 且重启了没、客户端连接串里有没有 serverTimezone——漏掉任意一层,NOW() 就可能“慢 8 小时”。 Tplink企业版路由器WiFi名称的默认设置介绍(Tplink企业版路由器WiFi名称的默认设置是什么)
Tplink路由器灯常亮无法上网的原因分析(如何解决Tplink路由器灯常亮无法上网的问题)
Tplink千兆企业级路由器自动重启的作用和优势介绍(如何设置Tplink千兆企业级路由器自动重启功能)
一根天线的tplink路由器有哪些(一根天线的Tplink路由器的特点和优势介绍)
tplink路由器外网访问不了nas(Tplink路由器外网访问NAS的原因分析)
Tplink无法搜到路由器的原因分析(如何解决Tplink无法搜到路由器的问题)