应确保系统时间准确并配置MySQL正确识别时区：先校准系统时间（启用NTP）、设置正确系统时区、在my.cnf中使用default-time-zone指定时区（如'Asia/Shanghai'）、导入时区表，最后重启MySQL服务。
MySQL 服务端时间与系统时间不一致怎么办
MySQL 的 NOW()、CURRENT_TIMESTAMP 等函数返回的时间，取决于 MySQL 服务启动时读取的系统时区和当前系统时间。如果服务器系统时间不准（比如没开 NTP），或者 MySQL 启动后系统时间被手动改过，NOW() 就会“看起来慢/快几小时”。这不是 MySQL 自己的问题，而是它默认信任系统时间。
解决思路很简单：确保系统时间准确 + 让 MySQL 正确识别时区。
- 先用
date命令检查系统时间是否准确；不准确就配 NTP，比如systemctl enable --now chronyd - 确认系统时区：运行
timedatectl status，看Time zone行是否是你期望的（如Asia/Shanghai） - MySQL 启动前必须确保系统时区已设好——改完
/etc/localtime或用timedatectl set-timezone后，要重启mysqld，否则它仍按旧时区初始化
my.cnf 里 timezone 配置写 default-time-zone 还是 time_zone
只能用 default-time-zone。这是 my.cnf（或 mysqld.cnf）配置文件中唯一合法的全局时区设置项；time_zone 是 SQL 层变量名，不能写在配置文件里。
常见错误是把 SQL 语句里的写法照搬进配置：
default-time-zone = '+08:00'
或（更推荐）用命名时区：
default-time-zone = 'Asia/Shanghai'
- 用
+08:00简单，但不支持夏令时；用Asia/Shanghai更健壮，前提是 MySQL 时区表已加载（见下一条） - 改完配置必须重启 MySQL：
systemctl restart mysqld，热重载不生效 - 如果启动失败，大概率是命名时区未加载，报错类似
Unknown or incorrect time zone: 'Asia/Shanghai'
ERROR 1298 (HY000): Unknown or incorrect time zone 错误怎么修
这个错说明 MySQL 不认识你写的时区名，根本原因是时区表（mysql.time_zone_*）为空。MySQL 默认不自动填充这些表，得手动导入。
操作分两步：
- 用系统命令生成时区 SQL 文件：
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql（路径可能为/usr/share/zoneinfo/或/usr/lib/zoneinfo/，用find /usr -name zoneinfo -type d 2>/dev/null确认） - 执行后检查：连接 MySQL，运行
SELECT COUNT(*) FROM mysql.time_zone_name;，结果应 > 0（通常几百条） - 如果提示
mysql_tzinfo_to_sql: command not found，说明 MySQL 客户端工具包没装全，CentOS/RHEL 上装mysql-community-client，Ubuntu/Debian 上装mysql-client
应用层写入时间用 NOW() 还是传入 PHP/Java 生成的时间字符串
优先用 NOW() 或 CURRENT_TIMESTAMP，但前提是上面所有环节都已校准。否则，不如由应用层统一生成带时区的 ISO 时间字符串（如 2024-05-20T14:30:00+08:00）再插入。
原因很实际：
-
NOW()依赖 MySQL 服务端时间，一旦集群多实例部署且各机器时间不同步，同一事务在不同节点上生成的时间戳就可能倒序 - 应用层生成时间能保证逻辑时间一致，尤其适合分布式场景；但要注意应用服务器时钟也要走 NTP
- 如果必须用服务端函数，至少把
explicit_defaults_for_timestamp=ON加进 my.cnf，避免老版本 MySQL 对TIMESTAMP字段的隐式行为干扰
真正麻烦的不是配置本身，而是时间同步这件事横跨系统、MySQL、应用三层，任何一层掉链子，查问题时都会以为是另一层的锅。
