關於數據遷移的記錄

背景

  前段時間完成了一個重構項目的數萬數據的遷移（爲了提高系統性能以及業務的合理劃分，從系統A中重構出系統B，數據庫從SQL SERVER變爲MYSQL），上線後遇到了一些問題，在此記錄下來提醒本身之後的數據遷移該注意哪些方面。

問題彙總

1. 遷移過程當中腳本出現問題
2. 遷移完成後，部分數據是錯的

緣由

  對於第一點，這裏出現問題的緣由是一個是線上數據業務表的字段長度遠大於新表, 致使新表數據沒法新增報錯或者批量新增的腳本太多執行報錯。腳本在測試環境跑過，可是與線上數據相差較大，線上數據不管是數據量和單個業務表的字段長度遠大於新表
  第二點的一個緣由業務表的字段沒有理解清楚，不夠透徹，好比原表有如下四個字段表示商品的長寬（舉例）：a，b,historyA,historyB，遷移數據時理所固然的使用了a，b，沒有去了解另外兩個字段表明的意義（historyA，historyB是原始尺寸，a，b是特殊規則後的尺寸），致使線上遷移的數據只要是須要特殊服務的尺寸全是錯誤。另外一個緣由是遷移腳本漏了一個重要業務數據的標識，這一點其實能夠在測試環境能夠發現的，主要是因爲這個重要業務能測試的帳號少，加上我日常不多進行這個操做，心存僥倖以爲沒問題形成了這個後果。

總結

  通過此次遷移數據後，我對遷移數據有了如下幾點思考

1. 遷移數據要用正式環境數據進行測試，並且要多演練幾回
2. 遷移數據腳本編寫前，遷移要多作調研，寧願多花時間在前期的調研上，也不要等出現問題再來解決
3. 新庫的數據表，每個字段都要反覆覈對它對應得是原表的哪一個字段
4. 遷移腳本每一行都要通過代碼審查，這一點要求審查人員必定是特別熟悉原業務的，你們一塊兒走查代碼才能發現潛在的問題並解決

你們還有什麼好的遷移數據方法，歡迎一塊兒討論。