数据库时间戳不匹配：mysqldump导出与Web应用显示不一致

这问题我之前帮好几个开发者排查过，十有八九是时区相关的坑，咱们一步步拆解可能的原因：

• 数据库与Web应用的时区不匹配
  这是最常见的原因。先检查MySQL的时区配置，执行这条命令：

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

  看看返回的时区是不是和你的Web应用服务器时区一致。比如数据库用UTC，而应用服务器用东八区（Asia/Shanghai），那读取时间时就会自动加上8小时，导致显示错误。同时也要检查应用的时区设置：比如PHP里的date_default_timezone_get()，Python里的import datetime; print(datetime.datetime.now().tzinfo)，确保两边时区统一。

• mysqldump导出/导入时的时区参数问题
  mysqldump默认会用服务器时区导出数据，如果你导出时没指定时区参数，或者导入到另一个时区不同的数据库，就会导致时间偏差。可以尝试导出时加上时区参数，比如：

  mysqldump --default-time-zone='+08:00' -u username -p database > dump.sql
  

  （把+08:00换成你实际需要的时区），然后重新导入看看应用显示是否正常。

• 应用层的时间处理逻辑出错
  检查应用里读取created_at后的转换代码：有没有不小心把timestamp类型当成datetime处理？有没有手动做了时间加减操作？比如有些ORM框架（像Laravel、Django）会自动处理时区转换，如果框架配置文件里的时区没设对，就会出现显示错误。举个例子，Laravel里如果.env文件的APP_TIMEZONE设成了UTC，但实际需要的是Asia/Shanghai，就会导致时间显示差8小时。

• 数据库字段类型的隐性转换
  虽然你说created_at是timestamp类型，但还是建议确认一下：执行SHOW CREATE TABLE orders;，看看字段定义是不是TIMESTAMP而不是DATETIME。因为MySQL的TIMESTAMP类型会自动把存储的时间转成UTC，读取时再转成服务器时区；而DATETIME是原样存储。如果服务器时区被修改过，TIMESTAMP的读取结果就会变化。

快速排查步骤 #

1. 先在数据库里直接查询：SELECT created_at FROM orders WHERE id=1;，如果返回的时间是正确的，那问题肯定在应用层或者数据库连接的时区设置。
2. 如果数据库查询结果就不对，那大概率是数据库时区配置错误，或者之前导入数据时的时区参数有误。

内容的提问来源于stack exchange，提问作者Hasan Hafiz Pasha