一般的網站應用中，總會有部分二次數據（處理過的原始數據）展現給前台，比如，拿購物網站來說，購買進口奶粉最多的用戶群體；哪類產品消費增長趨勢最旺盛；用戶的消費歷史歸類等都是二次數據。由於這部分數據通常是分析后的數據，而且實時性不強，因此這個過程通常是通過離線計算得到。為了展現給前台，需要將這部分數據回流到關系型數據庫【離線計算集群一般都是KV存儲，不支持SQL】，供前端用戶查詢。
對於MYSQL而言，數據回流實質就是通過mysqlimport或load data infile語句將離線計算的結果導入到數據庫中。mysqlimport實質是對load data infile的封裝，所以搞清楚load data infile的原理，和使用過程中需要注意的事項，就搞清楚了mysql數據回流。
load data infile語法，大家可以通過mysql官方手冊查看，這里就不copy-paste了，這里主要介紹下原理和流程，下面所描述的都是針對innodb存儲引擎，復制采用行級復制的情況。流程如下：
(1)主數據庫進行 ‘Load’ 操作
(2)主數據庫操作完成后，才開始向slave傳輸 load.txt文件，
(3)slave接受文件，並在 slave_load_tmpdir 目錄下生成 load.txt 文件，接受並生成完整的load.txt 后，才開始讀取該文件，並將數據插入到本地表中。
備注：由於innodb是事務型的，所以會把load文件的整個操作當作一個事務來處理，中途中斷load操作，會導致回滾。
load data infile 結構圖【來自網絡】
在執行load data infile前，一定要根據實際情況設置好以下幾個參數，否則很有可能因為參數設置不對，導致load失敗。
slave_load_tmpdir
含義：load data infile 存放臨時文件的目錄
建議：這個目錄所在磁盤空間應該足夠大，防止因為目錄空間不足，導致失敗的情況。
max_allowed_packet
含義：客戶端/服務器之間通信的緩存區的最大大小。
最大值：1G
建議：因此對於含有大字段(BLOB,TEXT)的表操作，或主備之間含有大事務傳遞時，需要調大該值，否則會出現max_allowed_packet不夠大的錯誤。
max_binlog_cache_size
含義：用來限制用來緩存多語句事務的緩沖區總大小。如果某個事務大於該值，將會失敗並回滾。
最大值：4G(32位)，16PB(64位)
建議：對於load data infile，或mysqlimport導入大文件時，由於是作為一個事務，很可能導致max_binlog_cache_size不夠，而出現錯誤導致回滾的情況。
max_binlog_size
含義：事務以一個塊寫入二進制日志，當超過max_binlog_size時，文件進行切換。
於max_binlog_size。
最大值：1G
建議：這個值設置不會導致執行報錯的情況。但是，有一點要注意，單個事務的binlog不會跨binlog文件，因此大事務可能導致binlog文件超出max_binlog_size值。
本人在使用mysql進行load時，遇到過好幾個問題，都是與以上幾個參數有關。
1.max_binlog_cache_size不夠大，主庫導入出錯，或從庫復制出錯；
解決方法：調大該值
2.max_allowed_packet不夠大，導致從庫io_thread拉binlog失敗，主備復制中斷。
解決方法：
1.調大該值
2.重新建立復制關系
(1).記錄目前復制的位置(Relay_Master_Log_File, Exec_Master_Log_Pos);
(2).reset slave [清理掉無效的relay-log，和master-info信息]
(3).執行change master to 命令
(4).start slave
大部分情況下，執行第一步后，start slave應該就可以了；但我碰到過，重啟復制后依然報錯的情況，主要原因是max_allowed_packet不夠大，relay-log只記錄了事務的一部分，復制報錯。那么，通過重建復制關系，則會重新開始拉事務的binlog，relay-log完整后，就不存在問題了。