log_timestamps设为system可解决mysql日志时间不准问题，因其决定错误日志、慢查询日志等时间戳时区，优先于系统时区；默认utc导致比北京时间晚8小时，需配置文件修改并重启生效。
MySQL 错误日志（error log）默认使用服务器本地时区记录时间戳，但当系统时区变更、容器化部署或跨时区迁移时，常出现日志时间与实际系统时间不一致的问题。关键在于 log_timestamps 系统变量——它控制错误日志、慢查询日志和通用查询日志中时间戳的时区，**不影响二进制日志（binlog）**。
log_timestamps 的作用与可选值
该变量决定日志中时间戳以何种时区输出，仅影响日志内容显示，不改变 MySQL 内部时间计算逻辑：
-
SYSTEM：使用操作系统的当前时区（即
date命令显示的时区），日志时间与date输出一致； - UTC：强制所有日志时间戳统一为 UTC，适合多时区集中日志分析；
- LOCAL：等同于 SYSTEM（MySQL 5.7.21+ 中已标记为废弃，不建议使用）。
确认当前时区配置与系统时间一致性
先检查 MySQL 是否已按预期运行在目标时区：
- 执行
SELECT @@global.log_timestamps;查看当前设置； - 运行
SELECT NOW(), SYSDATE(), UNIX_TIMESTAMP();验证 MySQL 服务时间是否与系统时间同步； - 在终端执行
date和timedatectl status（Linux）确认系统时区已正确设置（如Asia/Shanghai）； - 若 MySQL 时间明显滞后或超前，需检查是否启用了 NTP 同步，或容器是否挂载了错误的
/etc/localtime。
动态修改 log_timestamps 并验证效果
无需重启 MySQL 即可生效（但仅对新写入的日志有效）：
- 执行
SET GLOBAL log_timestamps = 'SYSTEM';切换为系统时区； - 触发一次错误（例如
SELECT * FROM nonexistent_table;）或手动刷新错误日志：FLUSH ERROR LOGS;； - 立即查看错误日志（路径由
log_error变量指定，如/var/log/mysql/error.log），确认新条目时间与date输出一致； - 若仍不一致，重点排查：MySQL 进程是否继承了错误的环境时区（如容器启动时未设置
TZ环境变量）、/etc/timezone与/etc/localtime是否匹配。
持久化配置避免重启失效
将设置写入 MySQL 配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）的 [mysqld] 段落：
[mysqld] log_timestamps = SYSTEM
保存后重启 MySQL（或使用 mysqladmin shutdown + 手动启动）使配置成为默认行为。注意：某些云数据库（如阿里云 RDS、AWS RDS）不支持修改该参数，需通过控制台或工单申请调整。
