log_timestamps是mysql专控错误日志、慢查询日志和通用查询日志时间戳时区的系统变量，默认utc导致比北京时间晚8小时；它优先级高于time_zone，后者仅影响now()等sql函数，而log_timestamps必须设为system并重启mysql才生效。
因为 log_timestamps 默认是 UTC，不是系统时区，也不是 MySQL 的 time_zone 设置 —— 这个变量单独控制日志时间戳，且优先级最高。
log_timestamps 是什么，为什么它比 time_zone 更关键
MySQL 的 time_zone 变量只影响 NOW()、SYS_DATE() 等 SQL 函数返回值；而 log_timestamps 是独立系统变量，专管错误日志、慢查询日志、通用查询日志里的时间戳输出时区。即使 time_zone 设为 +08:00 或 Asia/Shanghai，只要 log_timestamps 还是 UTC，慢查询日志里每条记录仍会比 date 命令输出早 8 小时（即显示为北京时间前一天 16:00，实际是当天 00:00 UTC）。
-
SYSTEM：用操作系统当前时区（推荐，与date输出完全一致） -
UTC：默认值，强制所有日志用协调世界时 -
LOCAL：MySQL 5.7.21+ 已废弃，8.0.19+ 直接忽略，设了也无效
怎么确认当前生效的 log_timestamps 值
别只看配置文件，直接查运行时变量最可靠：
SHOW VARIABLES LIKE 'log_timestamps';
返回结果必须是 SYSTEM 才算生效。常见误区：
- 误以为改了
default-time-zone就够了 —— 它不影响日志时间 - 执行
SET GLOBAL log_timestamps = 'SYSTEM'—— 在 MySQL 5.7.2+ 和 8.0 中这是只读变量，命令会报错ERROR 1238 (HY000): Variable 'log_timestamps' is a read only variable - 改完配置没重启 mysqld —— 修改
my.cnf后必须重启服务才生效
修改配置并验证的实操步骤
编辑 MySQL 配置文件（如 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），在 [mysqld] 段下添加：
[mysqld] log_timestamps = SYSTEM
然后重启服务：
systemctl restart mysqld
验证流程必须闭环：
- 重启后立即执行
SHOW VARIABLES LIKE 'log_timestamps';，确认返回SYSTEM - 触发一条慢查询：
SELECT SLEEP(3);（前提是long_query_time≤ 3） - 用
tail -n 1 /var/log/mysql/slow-query.log查最新行，对比终端date输出 —— 注意是“秒级”对齐，不是只看小时 - 如果仍不准，先检查
slow_query_log_file路径权限和磁盘空间，而不是继续调时区
容易被忽略的兼容性与环境细节
云数据库和容器环境最容易踩坑：
- 阿里云 RDS 5.6、部分 AWS RDS 实例不支持
log_timestamps参数，配置后启动失败，需走工单或控制台调整 - Docker 容器里 MySQL 进程可能没继承宿主机时区：即使宿主机
timedatectl正确，容器内date错，log_timestamps = SYSTEM也会写错时间 —— 必须挂载/etc/localtime或设置TZ环境变量 -
log_timestamps不影响binlog时间戳，后者始终跟随系统时钟，无需也不该通过此参数调整
真正生效的只有配置文件 + 重启这一条路，动态 SET 不行，default-time-zone 无关，NTP 同步只是基础前提而非解决方案。
