Thinking more...

在大致看過原始檔案以後，可以知道原始檔案大致的格式是是這樣：

• 每筆記錄以只有 '@' 存在的行做分隔。
• 每筆欄位，也就是每行以 @field: value 存在。
• @content: 該行比較特別，有可能是多行，有可能是單行。

最 簡單的想法就是逐行解析。一開始是先寫了一個小程式，確定一下有哪些欄位，結果這樣就執行了好久好久。所以為了實驗方便，後來改以 head -n 2000000 | tail -n 1000000 大致取了一小段來使用，來確定有多少欄位。為了以防萬一，有刻意改變數字，從尾段取部分、從中段取部分，確定三者得到的欄位都一致，就確定了 MySQL table 所需的欄位。這應該也算是統計吧，以採樣的方式來取得概略值。(之後稱這些部分的檔案為樣本檔)
接著用 grep '@content:' | wc -l 算了一下樣本檔，想不到這樣就有上萬筆!! 看來逐行解析然後新增到 MySQL 伺服器裡是不太現實的，不管是新增或是導出 SQL 敘述檔案肯定都會花許多的時間。因此就改變策略，要把每筆記錄都輸出到檔案，然後再根據檔案來逐檔轉換。但是這樣也出了問題，Linux 檔案系統的 inode 就這樣被我用盡，即使 df 的結果顯示還有空間，但就是沒辦法再新增檔案了。只好再次改變策略，分割為每十萬筆記錄為一個檔案。
針對檔案的解析並不難，那想要直接輸出 SQL 敘述，使用字串參數的方式未免太麻煩。這裡藉助了 mosql 模組的幫忙，只要丟一個 dict 進去，可以很簡單的輸出 SQL INSERT 敘述。
接著為了要讓 CPU 能用到所有核心，使用了 python 的 multiprocessing 模組，先把上述分割好的檔案名稱存為 list，然後以 multiprocessing.Pool 的 map 方法去執行，這樣就大幅的縮短了處理時間。
針對大型的檔案處理，必須要分割為多個小檔案，才能善用運算資源，速度才會快。