共計 4175 個字符，預計需要花費 11 分鐘才能閱讀完成。
這期內(nèi)容當中丸趣 TV 小編將會給大家?guī)碛嘘P如何解析 mysql 的坑比時區(qū)問題，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
問題：mysqldump 出來的文件遷移到另外的庫，時間戳字段總是少 8 個小時！
1. 看到這個很快就想到時區(qū)問題，我們先看一下
mysql 時區(qū)
mysql show variables like %zone%
+——————+——–+
| Variable_name | Value |
+——————+——–+
| system_time_zone | CST |
| time_zone | SYSTEM |
+——————+——–+
系統(tǒng)時區(qū)
[root@iZ2ze66bhrbxkc31nljgjnZ ~]# date -R
Fri, 23 Jun 2017 16:06:46 +0800
很好沒毛病
2. 查看表結構
MariaDB [ecejmaster] desc svc_street_tmp_170623;
+————–+————-+——+—–+——————-+—————————–+
| Field | Type | Null | Key | Default | Extra |
+————–+————-+——+—–+——————-+—————————–+
| street_id | int(11) | NO | | 0 | |
| city_id | int(11) | YES | | NULL | |
| street_name | varchar(50) | NO | | | |
| status | tinyint(4) | YES | | NULL | |
| create_user | int(11) | YES | | NULL | |
| create_time | datetime | NO | | CURRENT_TIMESTAMP | |
| update_user | int(11) | YES | | NULL | |
| update_time | datetime | YES | | NULL | |
| del_flag | tinyint(4) | NO | | 0 | |
| screate_time | timestamp | NO | | CURRENT_TIMESTAMP | |
| supdate_time | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
+————–+————-+——+—–+——————-+—————————–+
3 查看數(shù)據(jù)
MariaDB [ecejmaster] select * from svc_street_tmp_170623 where street_id=17615 limit 1;
+———–+———+————-+——–+————-+———————+————-+———————+———-+———————+———————+
| street_id | city_id | street_name | status | create_user | create_time | update_user | update_time | del_flag | screate_time | supdate_time |
+———–+———+————-+——–+————-+———————+————-+———————+———-+———————+———————+
| 17615 | 69 | 123 | 2 | 1 | 2017-06-23 15:37:24 | 1 | 2017-06-23 15:37:24 | 0 | 2017-06-23 15:37:24 | 2017-06-23 15:38:36 |
+———–+———+————-+——–+————-+———————+————-+———————+———-+———————+———————+
1 row in set (0.00 sec)
4 備份 [dbaadmin@YZ-PRO-DB-04 ~]$ mysqldump -udbmanager -p 12fAK1aR -h 10.32.14.78 ecejmaster svc_street_tmp_170623 –where= street_id=17615 -t
— MySQL dump 10.15 Distrib 10.0.23-MariaDB, for Linux (x86_64)
—
— Host: 10.32.14.78 Database: ecejmaster
— ——————————————————
— Server version 10.0.23-MariaDB-log
/*!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_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 */;
—
— Dumping data for table `svc_street_tmp_170623`
—
— WHERE: street_id=17615
LOCK TABLES `svc_street_tmp_170623` WRITE;
/*!40000 ALTER TABLE `svc_street_tmp_170623` DISABLE KEYS */;
INSERT INTO `svc_street_tmp_170623` VALUES (17615,69, 123 ,2,1, 2017-06-23 15:37:24 ,1, 2017-06-23 15:37:24 ,0, 2017-06-23 07:37:24 , 2017-06-23 07:38:36);
/*!40000 ALTER TABLE `svc_street_tmp_170623` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */
—- 看到?jīng)]，時間少了 8 個小時，仔細觀察會發(fā)現(xiàn) timestamp 時間戳會出現(xiàn)少 8 個小時的狀況，datetime 時間類型不會！插入到另外的庫中，時間會再加 8 個小時，恢復正常
但是：如果 dump 時指定 -t 等參數(shù)（忽略了上面的 set time_zone），再插回去就真的少 8 個小時了。剛好我們備份的全是 insert 語句，其它的信息全部去掉了
5 看下 mysqldump 的說明 [dbaadmin@YZ-PRO-DB-04 ~]$ mysqldump –help | grep -i zone
–tz-utc SET TIME_ZONE= +00:00 at top of dump to allow dumping of
zones or data is being moved between servers with
different time zones.
默認是以 0 時區(qū)來導出的，會對 timestamp 時間類型造成影響
6 解決辦法：
mysqldump -uroot -S /data/3306/mysql.sock -pHP2T9wypjr6oEZRV ecejmaster3 $i –compact -c -t –skip-extended-insert –skip-tz-utc 跳過時區(qū)
mysqldump 會對 timestamp 時間類型的字段造成 8 個小時的誤差，存 insert 時使用 skip-tz-utc 跳過時區(qū)的方式導出解決
上述就是丸趣 TV 小編為大家分享的如何解析 mysql 的坑比時區(qū)問題了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業(yè)資訊頻道。
