mysqldump導出CSV格式及where導出時間範圍問題解決

　　衆所周知，mysqldump不但能夠導出sql格式，還能夠導出csv格式。

　　導出CSV格式的具體使用以下命令。

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

　　導出後，會生成2個文件，一個tablename.sql爲表結構，另外一個tablename.txt爲數據內容。

　　須要注意的是：

　　一、-T 參數跟的是目錄path，不是文件名。

　　二、這個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'

　　三、使用的用戶須要有select和file2個權限。

　　四、使用fields-terminated-by和lines-terminated-by能夠自定義字段分割符和行分隔符

　　五、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，其實問題的解決方法都已經放在了哪裏。