mysql 5.7 的 slow_log 表时间戳比系统时间慢 8 小时，是因为其依赖只读变量 @@global.system_time_zone（启动时读取的系统时区），若启动时系统时区未正确设为 asia/shanghai 或被误识别为 utc，就会导致时间偏移；需通过 timedatectl 设置系统时区、配置 default-time-zone='+08:00' 并重启 mysql 才能永久修复。

MySQL 5.7 的 slow_log 表时间戳为什么比系统时间慢 8 小时？

因为 slow_log 表（如果启用为表存储）默认使用 MySQL 服务的系统时区（system_time_zone），而该值在 MySQL 启动时读取一次，不随系统时区变更自动更新；若系统已切到 CST（如 Asia/Shanghai），但 MySQL 启动时系统时区是 UTC 或未正确识别，就会导致日志时间偏移。

常见现象包括：

• SELECT NOW() 返回时间正确，但 SELECT * FROM mysql.slow_log LIMIT 1 中的 start_time 晚/早 8 小时
• mysqld 进程启动后改过 /etc/localtime，但 MySQL 未重启，system_time_zone 仍为旧值

确认当前 MySQL 时区设置的三个关键变量

运行以下查询一次性看清差异：

SELECT @@global.time_zone, @@session.time_zone, @@global.system_time_zone;

• @@global.time_zone：影响 NOW()、SYSDATE() 等函数，默认常为 SYSTEM
• @@session.time_zone：当前连接会话时区，可临时设为 '+08:00'，但不影响慢日志写入
• @@global.system_time_zone：只读变量，反映 mysqld 启动时读到的系统时区名称（如 CST 或 UTC），慢日志时间戳完全依赖它

注意：system_time_zone 无法 SET 修改，只能靠重启生效。

永久修正 slow_log 时间戳需同步三处

• 确保系统时区已正确设置（非仅软链接）：

  

  MySQL

  编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

  下载
  • 执行 timedatectl set-timezone Asia/Shanghai（推荐，兼容 systemd）
  • 验证：date 和 timedatectl status 输出应一致且含 “CST” 或 “+0800”

• 修改 MySQL 配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），在 [mysqld] 下添加：

  default-time-zone = '+08:00'

  > ⚠️ 不要用 default-time-zone = 'Asia/Shanghai' —— MySQL 5.7 对命名时区支持有限，且依赖 mysql.time_zone* 表是否导入，易失败。

• 必须重启 mysqld：

  sudo systemctl restart mysql

  重启后再次查 @@global.system_time_zone，应显示 CST（只要系统时区正确，MySQL 5.7 通常能识别为 CST）；slow_log.start_time 新增记录即与系统时间一致。

临时补救：查询 slow_log 时手动转换时间

如果暂时无法重启 MySQL，又急需分析日志，可用以下方式对齐时间：

SELECT 
  CONVERT_TZ(start_time, '+00:00', '+08:00') AS local_start_time,
  sql_text 
FROM mysql.slow_log 
ORDER BY start_time DESC LIMIT 10;

但注意：

• CONVERT_TZ() 在 system_time_zone = 'UTC' 时才有效，若它显示 CST 却仍偏移，说明该 CST 被误识别为美国中部时间（UTC-6），此时应强制用数值偏移：

  CONVERT_TZ(start_time, '-06:00', '+08:00')

• 此法仅用于查询，不改变写入行为，慢日志表本身的时间字段仍是错的。

真正起效的只有重启 + default-time-zone = '+08:00'。别信“SET GLOBAL time_zone”能修 slow_log——它对日志写入无影响。