共計 2918 個字符，預計需要花費 8 分鐘才能閱讀完成。
這篇文章給大家分享的是有關 mysqlimport 如何排查導入報錯問題的內容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。
之前有個同事問我一個 mysqlimport 導入的問題，看起來還是蠻奇怪的。同事在客戶端導入一個文件。文件大小是 2.8G，然后報錯 mysqlimport: Error: 2013, Lost connection to MySQL server during query
對于這個問題我的第一感覺是一臺云服務器，是不是沒有配置 swap 造成的原因，因為在之前的一次遷移中，被這類問題折磨壞了，遭遇了 OOM-Killer 的問題，最后發現是 swap 沒有配置導致的。
但是同事經過確認，這是一臺實體機，而且查看硬件情況，配置還不錯。buffer_pool_size 有 50 多 G，swap 也配置了。看來這個問題的原因初步排除了。
對于這個問題，網絡上也有很多種說法。有的說是 max_allowed_packets 導致。查看當前的配置是 1G，看起來是比導入文件小了。
不過從 Oracle 中的經驗來看，似乎這個說法也不是完全靠得住的，如果我導入一個 100G 的 dump，那這個參數還要配置超過 100G，好像聽起來也不大合理啊。而且也沒見過有環境配置一個極高的值。
為此我做了幾個簡單的測試。
首先找了一個測試環境,max_allowed_packets 為 30 多 M.
# mysqladmin var|grep max_all
| max_allowed_packet | 33554432
| slave_max_allowed_packet | 1073741824
鎖定了一個小表.
] select count(*)from t_fund_info;
+———-+
| count(*) |
+———-+
| 1998067 |
通過查看文件大小，大概是 400 多 M.
-rw-rw—- 1 mysql mysql 482344960 Oct 13 16:01 t_fund_info.ibd
這樣就可以輕松模擬測試 max_allowed_packets 的場景了。
首先導出文件。
select * from t_fund_info into outfile /tmp/t_fund_info.txt
Query OK, 1998067 rows affected (6.82 sec)
導出的文本文件有近 300M
ll t_fund_info.txt
-rw-rw-rw- 1 mysql mysql 291963062 Oct 20 22:25 t_fund_info.txt
然后使用最簡單的命令來導入：
mysqlimport test /tmp/t_fund_info.txt
短暫的等待之后，成功導入。
可以看到慢日志的輸出如下：
# Time: 161020 22:31:49
# User@Host: root[root] @ localhost []
# Thread_id: 4321910 Schema: test Last_errno: 0 Killed: 0
# Query_time: 92.866443 Lock_time: 0.000074 Rows_sent: 0 Rows_examined: 0 Rows_affected: 1998067 Rows_read: 0
# Bytes_sent: 68
SET timestamp=1476973909;
LOAD DATA INFILE /tmp/t_fund_info.txt INTO TABLE `t_fund_info` IGNORE 0 LINES;
原來 mysqlimport 會轉換為 load data 的形式。
然后 delete,truncate,drop 重建，都可以成功導入。
是哪里測試的不到位嗎，我開始審視這個問題，我們可以在測試環境中模擬這個問題，以當時出問題的數據為準。然后查看同事提供的日志和截圖，發現當時使用的命令是
mysqlimport test /tmp/t_charextra.txt –local –delete –default-character=gbk
這個表的字符集經過確認是 latin, 所以就在懷疑是不是因為字符集轉換造成的。
ENGINE=InnoDB DEFAULT CHARSET=latin1
但是短暫的等待之后，還是可以成功導入。
# mysqlimport test /tmp/t_charextra.txt –local –delete –default-character=gbk
test.t_charextra: Records: 480174 Deleted: 0 Skipped: 0 Warnings: 0
在表 t_charextra 存在大量數據的前提下，我們繼續嘗試上面的方法導入。
整個導入就會分為兩部分，
SET timestamp=1476975647;
DELETE FROM t_charextra
SET timestamp=1476975748;
LOAD DATA LOCAL INFILE /tmp/t_charextra.txt INTO TABLE `t_charextra` IGNORE 0 LINES;
還是能夠成功導入
# mysqlimport test /tmp/t_charextra.txt –local –delete –default-character=gbk
test.t_charextra: Records: 480174 Deleted: 0 Skipped: 0 Warnings: 0
是哪里測試的不到位嗎，現在唯一能夠想到的就是兩點，一是通過客戶端調用，而是客戶端和服務端的網絡延遲較大。
配置了客戶端用戶，把導出的文本拷貝到客戶端來復現問題。
grant select,insert,delete on test.* to testdb@10.127.133.86 identified by mysqlnew
Query OK, 0 rows affected (0.02 sec)
然后使用下面的命令來嘗試客戶端導入。
# mysqlimport -h 10.127.xxxx -utestdb -pmysqlnew test /U01/t_charextra.txt –local –delete –default-character=gbk
Warning: Using unique option prefix default-character instead of default-character-set is deprecated and will be removed in a future release. Please use the full name instead.
test.t_charextra: Records: 480174 Deleted: 0 Skipped: 0 Warnings: 0
從日志看除了拋出一個警告外，一切都很正常，所以現在的重點就落在了網絡上，這一點還是需要進一步確認，不過目前來看已經排除了不少原因，想必原因也快揭曉了。
感謝各位的閱讀！關于“mysqlimport 如何排查導入報錯問題”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
