一. 場景
現有倆個體積較大的單表sql文件，一個為8G，一個為4G，要在一天內完整導入到阿里雲的mysql中，需要同時蠻子時間和空間這倆種要求。
二. 思路
搜索了網上一堆的方案，總結了如下幾個：
方案一：利用navicat遠程導入
方案二：在阿里雲ECS安裝一個mysql-client，用source方案導入
方案三：購買阿里雲DBMS高級版服務，可以導入1G以內ZIP壓縮包
三. 嘗試
折騰了許久的嘗試，終於總結了一下的經驗：
3.1 嘗試navicat遠程導入
操作簡單，但是缺點很明顯：導入效率低，嚴重占用本地的IO，影響機器的正常工作，所以立馬放棄。
3.2 嘗試source方案
3.2.1 實現步驟
STEP1 在測試環境的ECS上安裝一個mysql-client
STEP2 修改mysql中的max_allowed_packet參數為10G大小，net_buffer_length參數也根據需求適度調大。
STEP3 因為是倆個表，寫倆個腳本太麻煩了，可以利用一個sql腳本聚合實現，所以all.sql 的內容可以如下
source /mydata/sql/a.sql;
source /mydata/sql/b.sql;
STEP4 為避免ssh連接掉線而導致執行關閉，需要寫一個shell腳本，通過nohup后台執行。
myshell.sh腳本如下
mysql -h host -uxxx -pxxx --database=user_database</mydata/sql/all.sql
STEP5 后台執行指令
nohup ./myshell.sh &
3.2.2 結果
測試速度相對快多了，但是由於第二天就需要，所以倆個表接近4000w行的數據絕對不能完成任務，所以方案取消。但是不是否定該方案，其他場景肯定滿足。
3.3 嘗試DMBS
由於我們數據庫是阿里雲的RDS，所以我們購買了對應的DBMS服務升級版，可以支持文件上傳導入（包含1G內的ZIP）
3.3.1 壓縮文件
壓縮單表SQL文件為單獨zip文件，壓縮下來一個為0.9G，一個為1.2G
3.3.2 拆分文件
第一個sql文件上傳后執行很順利，但是第二個1.2G的zip包需要進行拆分
3.3.3 拆分方案
1.拆分zip壓縮包
拆分出來的文件，手動改后綴后不滿足DBMS的文件規范，失敗~
2.高比例壓縮文件
利用7z高比例壓縮sql為7z后綴，壓縮后體積明顯小了，只有0.7G的體積，然后通過更改后綴為zip來上傳。結果阿里雲解析不出這樣的格式，失敗~
3.使用linux split 命令
split [--help][--version][-<行數>][-b <字節>][-C <字節>][-l <行數>][要切割的文件][輸出文件名]
補充說明：
split可將文件切成較小的文件，預設每1000行會切成一個小文件。
-<行數>或-l<行數> 指定每多少行就要切成一個小文件。
-b<字節> 指定每多少字就要切成一個小文件。支持單位:m,k
-C<字節> 與-b參數類似，但切割時盡量維持每行的完整性。
雖然linux可以根據行拆分文件（這也是阿里雲工單提供的解決方案），但是這個操作上傳上去拆分，在下載下來上傳到DBMS，文件體積這么大，來來回回一天過去了，所以放棄~
4.拆分單表sql文件為多份
網上有個SQLDumpSplitter的工具可以拆分表為多份，但是搜索記錄中和文章中都是推薦SQLDumpSplitter2的版本，版本太老了，體積較大的sql完全不支持，失敗~
但是！我在SQLDumpSplitter2里面看到了軟件的官網，發現官網有SQLDumpSplitter3版本，不抱希望的嘗試了一下，居然支持大體積文件。成功了！！！
附帶下載鏈接：https://philiplb.de/sqldumpsplitter3/ 太值得推廣了。
剩下就是按序上傳對應文件即可完成，不得不得誇阿里雲這方面做得真的好！
執行效率上面來說，也是可圈可點的：
四. 總結
原文地址：https://www.jianshu.com/p/968fa5963d07今天針對這個需求，我首先查詢了網上的大體方案，然后挑選了幾個可執行的方案進行測試。排除了多個方案的情況下，采用了第三方的解決方案來完成這個問題。在阿里雲DBMS的支持下，我們又嘗試了多種文件的切割方案，最后通過SQLDumpSplitter3+DBMS來實現了，並且效率可觀。過程中也發現，常用的client-source方案可以滿足自建mysql+效率要求不是極致的場景。
綜上，對於大型sql，最好的方案也是先切割（確保順序性），然后利用一些更高效率的軟件執行來實現最終結果，也需要根據時間空間場景靈活選用方案。