mysql时间显示不一致源于服务端、客户端、字段类型三层时区规则冲突，需逐层对齐：先查@@global.time_zone等三变量及系统时区，再按场景配置default-time-zone、jdbc的servertimezone，并统一使用datetime避免timestamp自动转换问题。
MySQL时间显示不一致，根本不是“时间存错了”，而是服务端、客户端、字段类型三层解释规则打架。直接改default-time-zone不一定管用，得一层层对齐。
查清当前三层时区实际值
登录 MySQL 后立刻执行：SELECT @@global.time_zone, @@session.time_zone, @@system_time_zone;
再在终端跑：timedatectl | grep "Time zone"。常见陷阱是：@@global.time_zone返回 SYSTEM，但系统本身时区其实是 UTC——这时 MySQL 看起来没配错，实则已偏移 8 小时。
永久设置服务端时区（必须重启）
编辑 /etc/my.cnf 或 /etc/mysql/my.cnf，在 [mysqld] 段下写：
[mysqld] default-time-zone = '+08:00'
不推荐用 Asia/Shanghai，除非你确认已执行过：mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql
且验证过：SELECT COUNT(*) FROM mysql.time_zone_name WHERE Name = 'Asia/Shanghai'; 返回大于 0。Windows 用户直接用 '+08:00' 更稳妥。
JDBC 连接必须显式指定 serverTimezone
即使 MySQL 服务端设成 '+08:00'，JDBC 驱动（8.0+）默认仍按 JVM 本地时区解析时间，造成双重转换。连接串里必须带：
?serverTimezone=Asia/Shanghai&useTimezone=true
注意：
• GMT%2B8 在部分驱动中不被识别，优先用 IANA 名称
• spring.datasource.url 必须包含该参数，spring.jackson.time-zone 对数据库层完全无效
• 如果历史数据用 DATETIME 存了 UTC 时间，但业务一直当北京时间用，改时区毫无意义，只能靠 DATE_ADD(created_at, INTERVAL 8 HOUR) 批量修正
DATETIME 和 TIMESTAMP 的行为差异不能忽略
DATETIME 是纯字面值，time_zone 设置对它完全没影响；TIMESTAMP 存的是 UTC，读写时自动按会话时区转换。线上系统强烈建议统一用 DATETIME，并由应用层明确约定存储语义（比如“全部存 UTC”或“全部存 Asia/Shanghai”）。如果误用 TIMESTAMP 又没统一会话时区，同一个字段在 Navicat、Java 应用、命令行里查出来的时间字面值会各不相同。
