mysqldump导出CSV格式及where导出时间范围问题解决

　　众所周知，mysqldump不但可以导出sql格式，还可以导出csv格式。

　　导出CSV格式的具体使用如下命令。

mysqldump -uroot -ppassword -S /tmp/mysql9991.sock heartbeat -t -T /data1/mysql9991/

　　导出后，会生成2个文件，一个tablename.sql为表结构，另一个tablename.txt为数据内容。

　　需要注意的是：

　　1、-T 参数跟的是目录path，不是文件名。

　　2、这个path必须是导出源mysql具有可写权限的，否则报错如下。

mysqldump -uroot -ppassword -S /tmp/mysql9991.sock heartbeat alive -t -T /data1/
mysqldump: Got error: 1: Can't create/write to file '/data1/alive.txt' (Errcode: 13) when executing 'SELECT INTO OUTFILE'

　　3、使用的用户需要有select和file2个权限。

　　4、使用fields-terminated-by和lines-terminated-by可以自定义字段分割符和行分隔符

　　5、mysqldump导出csv格式只能在本地进行，无法远程操作。

---

 

　　但是很少有人知道mysqldump可以支持where条件导出，具体的方法如下：

mysqldump -uroot -ppassword -S /tmp/mysql9991.sock heartbeat alive -w "time between '2013-12-22 00:00:00' and '2013-12-22 23:59:59'" > 1.txt

　　或者

mysqldump -uroot -ppassword -S /tmp/mysql9991.sock heartbeat alive -w "time between '2013-12-22 00:00:00' and '2013-12-22 23:59:59'"  -t -T /data1/mysql9991/　　

　　最近利用利用这个特性在导出一个时间段的数据的时候突然发现遇到如下问题：

### 首先使用如下命令导出数据
mysqldump -uroot -ppasswrod -S /tmp/mysql9991.sock heartbeat alive -w "time between '2013-12-22 00:00:00' and '2013-12-22 23:59:59'" > 1.txt

### 查看内容ok
INSERT INTO `alive` VALUES ('2013-12-22 00:00:00','2013-12-22 00:00:00')...................省略n多内容。

### 重新导入库中后发现，内容变了
source 1.txt
select * from alive limit 3；

+---------------------+---------------------+
| time | systime |
+---------------------+---------------------+
| 2013-12-22 08:00:00 | 2013-12-22 08:00:00 |
| 2013-12-22 08:00:01 | 2013-12-22 08:00:01 |
| 2013-12-22 08:00:02 | 2013-12-22 08:00:02 |
+---------------------+---------------------+
3 rows in set (0.00 sec)

　　从上面我们可以看到，sql文件中的时间是12月22日0点0分0秒，那么为什么重新灌入库中就变成了12月22日8点0分0秒了呢？

　　聪明的同学应该已经反应出来了，8小时是标准的时区设置，这必然和时区有关。man一下mysqldump之后发现果然和时区有关，有个关键参数是--tz-utc这个参数解释如下:

 --tz-utc

          This option enables TIMESTAMP columns to be dumped and reloaded between servers in different time zones.
          mysqldump sets its connection time zone to UTC and adds SET TIME_ZONE=’+00:00’ to the dump file. Without this
          option, TIMESTAMP columns are dumped and reloaded in the time zones local to the source and destination
          servers, which can cause the values to change.  --tz-utc also protects against changes due to daylight saving
          time.  --tz-utc is enabled by default. To disable it, use --skip-tz-utc. This option was added in MySQL
          5.0.15.

　　从解释中看到，默认--tz-utc是打开的，而这个参数会影响timestamp的。他会默认设置时区为time_zone=‘+00:00’，而由于我们所在的时区是‘+08：00’所以自然会增加8个小时。（所在时区可以使用date +%z查询）

　　如解释中可以使用--skip-tz-utc来解决这个问题，我们重新dump一次，对比两次的文件可以更明显的看出来，没有添加参数的多出了time zone的配置。

### 第一次没有加参数的配置
/*!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' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

### 第二次添加 --skip-tz-utc
/*!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 */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

　　至此，问题解决。

　　突然发现，即使是我们经常使用的命令，依然有很多不知道的参数，看来还需要多多研究，另外就是，善用man，其实问题的解决方法都已经放在了哪里。

转载于:https://www.cnblogs.com/billyxp/p/3486672.html