MySQL 数据导出更改时间

Question

我有一些用于数据库的备份和恢复脚本。该表有一个时间戳字段。备份脚本如下所示:

mysqldump -u user -ppass database --tab="../" --fields-terminated-by="|" --skip-comments table

它创建了两个文件，table.sql 和 table.txt。恢复脚本如下所示:

mysql -u user -ppass database < "../table.sql"
mysqlimport -u user -ppass --local --fields-terminated-by="|" database "../table.txt"

然而，备份脚本输出了错误的时间 - 它比数据库中的时间晚了一个小时 - 但在导入时它并没有更正它。

例如，一行中的时间是15:10:25，但是当备份脚本运行时，table.txt 中列出了14:10:25。当我运行恢复脚本时，同一行现在有 14:10:25 作为数据库中的时间。如果我再次备份，它会显示 13:10:25!等等……

我不明白为什么会这样。时区似乎设置为“系统”(我在格林威治标准时间)。 table.sql 文件中有几行提到了时区，也许那里有问题？这是有问题的完整文件:

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
DROP TABLE IF EXISTS `news_article`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `news_article` (
  `id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
  `title` varchar(100) NOT NULL,
  `alias` varchar(65) NOT NULL,
  `author` tinyint(3) unsigned NOT NULL,
  `category` tinyint(3) unsigned NOT NULL,
  `posted` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `opening` text NOT NULL,
  `content` text NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `alias` (`alias`)
) ENGINE=MyISAM AUTO_INCREMENT=93 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

Answer 1

最后找到解决办法:在导出脚本中加入--skip-tz-utc选项。

这只是确保您导出的确切日期是在第二个数据库中导入的日期。它适用于我，因为数据库是相同的时区，但对于数据库不同时区的其他人来说可能并不理想。