只需将sql数据库从一台服务器移动到另一台
我知道MYSQL中的时间戳字段存储为4字节整数(时区不可知)，并在其当前服务器(MYSQL-server)时区设置中显示给用户我说得对吗？
现在，在欧洲，当时间从夏令时间变为十月的收卷时间(UTC+2到UTC+1)时，时间会重叠一个小时。
这是有道理的，也不是问题，因为我们"知道"服务器知道区别，因为它将thim存储在unix utc时间戳中。
我还对吗？
现在，当我将数据库导出从一个数据库移动到另一个数据库时，时间戳字段并不是以整数形式移动的，而是作为一个人类可读的时间字符串：
只是一个样本：
(1,'AAAA01',6.50,NULL,NULL,NULL,'2017-07-28 17:38:16',0,NULL,NULL,NULL,NULL,0,NULL),
(2,'AAAA01',6.50,NULL,NULL,NULL,'2017-07-28 20:00:00',1,NULL,NULL,NULL,NULL,0,NULL),
(3,'AAAA01',6.00,NULL,NULL,NULL,'2017-07-28 21:39:07',0,NULL,NULL,NULL,NULL,0,NULL),
(4,'AAAA01',5.50,NULL,NULL,NULL,'2017-07-28 21:42:15',0,NULL,NULL,NULL,NULL,0,NULL),
(5,'AAAA01',5.00,NULL,NULL,NULL,'2017-07-29 12:55:48',0,NULL,NULL,NULL,NULL,0,NULL),
您可以看到这个字段：
`received` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
但是被存储为人类可读字段。
接收服务器如何知道该字段是在时间更改之前还是之后(10月)
时间变化一年发生两次，春天会提前一个小时，所以没有混乱，因为只有一个小时的间隔，但在秋天会倒退并"覆盖"同一个小时。。
时区转换
Mysql服务器怎么能给出这个时间的答案，因为它代表了两个不同的时间：
选择CONVERT_TZ("2018-10-28 02:40"，"欧洲/巴黎"，"UTC")
MySQL服务器的时区只是用于这些转换的默认时区。它可以在每个连接的基础上被覆盖。这就是发生的事情，在这里，使这项工作。
当mysqldump查询服务器以检索要写入备份文件的数据时，它首先发送以下消息：
SET TIME_ZONE='+00:00';
这将mysqldump连接的会话(连接)时区设置为UTC，这将导致服务器以UTC发送这些TIMESTAMP列，并以这种方式写入备份文件。
在转储文件的顶部附近，它还添加了以下内容：
/*!40103 SET TIME_ZONE='+00:00' */;
/*! ... */并不是一个真正的评论，尽管它看起来像一个评论。!40103向任何MySQL服务器4.01.03或更高版本发出信号，让其正常执行嵌入的语句，从而将正在恢复转储的连接上的会话时区设置为UTC，以便将这些时间戳作为字符串正确存储。
DATETIME列不执行这些转换--只有TIMESTAMP。。。但是对于TIMESTAMP列，新服务器上不应该有不正确的值。转储文件中的值是UTC，这也是本机内部存储格式的时区(在技术上根本不可知)。
请注意，将服务器的时区设置为UTC以外的任何时区都不再是最佳做法。本地时间是一个表示问题，最好由应用程序而不是数据库来处理。UTC没有像当地时区那样的模糊性，比如在许多当地时区中发现的春季的缺失时间和秋季的重复时间。