前言：

在前面文章中，有提到过 mysqldump 备份文件中记录的时间戳数据都是以 UTC 时区为基础的，在筛选恢复单库或单表时要注意时区差别。后来再次查看文档，发现 tz-utc、skip-tz-utc 参数与此有关，本篇文章我们一起来看下此参数的作用吧。

这两个参数可以作用于 mysqldump 备份过程中，互为相反参数。顾名思义可以看出，一个参数是将时间戳改为 UTC 时区，另一个是跳过时区变动。

在 mysql 服务器上执行 mysqldump --help 的命令，可以看到下面一段话。

--tz-utc 参数是 mysqldump 的默认参数，会使得 mysqldump 的导出文件的顶部加上一个设置时区的语句 SET TIME_ZONE='+00:00' ，这个时区是格林威治时间，也就是0时区。这样当导出 timestamp 时间戳字段时，会把在服务器设置的当前时区下显示的 timestamp 时间值转化为在格林威治时间下显示的时间。比如我们数据库采用北京时间东八区，mysqldump 导出的文件当中显示的 timestamp 时间值相对于通过数据库查询显示的时间倒退了8个小时。

知道了 --tz-utc ，那么 --skip-tz-utc 的含义就是当 mysqldump 导出数据时，不使用格林威治时间，而使用当前 mysql 服务器的时区进行导出，这样导出的数据中显示的 timestamp 时间值也和表中查询出来的时间值相同。

为了更清楚了解这对参数的作用，下面我们来具体测试下，我们知道 mysqldump 后可以跟 where 条件来备份部分数据，若根据 timestamp 字段来备份部分数据，这对参数是否有影响呢？我们一并来验证下：

先来看下我的环境设置及测试数据：

mysqldump 默认开启 tz-utc ，先来看下默认情况下的备份结果：

建议各位仔细看下上面导出结果，说实话，笔者原来也没做过详细测试，现在看到结果也是稍微有点吃惊的。默认情况下，全备出来的数据是没问题的，虽然将 timestamp 时间值转为0时区显示，但当你导入数据库时还会以你的数据库时区来展示 timestamp 时间。但使用 where 条件导出部分数据时，却出现了数据库中查询得出的结果与dump导出的结果不同的情况，这个时候 mysqldump 只导出了转化成0时区后的时间值符合 where 条件的数据，与直接查询出的结果有出入，这是我原来没注意到的。

再来看下使用 --skip-tz-utc 参数，看下这个参数是否符合我们的预期：

从上面结果可以看出，使用 --skip-tz-utc 参数后，timestamp 时间戳字段值不会转换，导出部分数据也符合预期。

那么这个参数的意义何在呢？当你的数据库服务器处于不同时区时。假设一个服务器在北京（东八区），一个服务器在东京（东九区），现在需要将北京服务器里的数据导入至东京服务器。当导入按照默认不加 --skip-tz-utc 参数的dump文件，查询的 timestamp 时间数据相对于在之前的东八区服务器的时间值多了一个小时，但由于东八区服务器里的13点和东九区服务器里的14点代表的是同一时刻，所以，在东九区的服务器里显示的多出的一个小时，这样显示是正确的。而如果增加 --skip-tz-utc 参数，dump文件导入东九区服务器后，尽管显示的时间值和之前东八区服务器显示的时间值相同，但两者代表的时刻却已经不同。

关于这个参数应该如何使用，我们首先应该明白，是否加上 --skip-tz-utc 参数，只会影响 timestamp 字段的导入导出，对 datetime 时间字段不会影响。

这里笔者建议首先对 timestamp 字段使用作出规范。比如 timestamp 字段只用于创建时间和更新时间需求，只代表该行数据的创建及更新时间，做到与业务弱相关，其他时间字段尽量使用 datetime 。这样即使 mysqldump 采用不同参数，实际产生影响也不大。

如果你的服务器处于不同时区，那建议还是按照默认来，这样导入导出的数据都是正确的。如果你的服务器都是处于同一时区，那么是否使用 --skip-tz-utc 参数区别不大，我们只需知道默认情况 mysqldump 会将 timestamp 时间值转为0时区存储即可。当备份部分数据且以 timestamp 字段来筛选时，这时候建议增加 --skip-tz-utc 参数。这里再次提醒下，从全备中筛选单库或单表的备份时，也要注意下 timestamp 字段数据。

参考：