快速備份和還原 MySQL 數據庫的另外一種方法

　　一直使用 SQL Server 做爲公司產品的數據庫來存儲系統數據，因此備份還原一直都不是問題，由於 SQL Server 的備份還原很是迅速和易用。但今年公司改變策略，使用起 MySQL 數據庫做爲新產品的數據庫後，咱們終於遇到了備份還原的大難題：咱們須要把客戶的數據庫備份並還原到開發環境中。咱們同時使用 HeidiSQL和 NaviCat for MySQL 做爲數據庫管理工具，使用這類工具的導出腳本功能，把整個數據庫導出爲一個SQL文件，而後在還原目標數據庫中執行該 SQL 文件以完成還原動做。原理很是簡單，但一個3GB大小的數據庫，備份以及還原竟然花費了70小時（無能否認咱們的服務器的確是有點慢）。這個速度不管讓人接受，也影響了客戶對咱們服務效率的評價。

　　通過分析發現，還源速度慢的主要緣由是由於這類工具在執行 SQL 文件的時候，老是把每一條SQL以一個事務的方式去執行。因此面對幾千萬的數據，就須要執行幾千萬次的 SQL 語句，效率更加可想而知。因而想到了 OBDB2DB 這一個數據庫轉換工具，經過這一個工具把 MySQL 的數據導出爲本地 SQLite 數據庫，帶回來後再將 SQLite 轉換爲 MySQL 數據庫。因爲 OBDB2DB 在進行數據轉換時採用了批量處理的方式，因此轉換速度相比原來的方式大大提升。

 

　　OBDB2DB 的使用很是簡單，首先按下圖將原數據庫導出爲 SQLite 數據庫：

 

　　通過短暫的等待以後，咱們就能夠獲得一個 DataBase.DB 的 SQLite 數據庫文件（文件名自定義）。把文件帶回到開發環境後，咱們使用相反的方法把 SQLite 還原到 MySQL 數據庫：

 

　　帶回的數據庫，在個人 W540 筆記本上只須要十分鐘就還原成功了。在那臺老慢的服務器上面還原，也減小至只須要 54 分鐘就還原成功！比原來的 70 小時提升了 N 十倍了。不過這個方法有一個缺點，由於是經過異構數據庫來進行數據備份和還原，因此視圖和存儲過程將不會被保留。不過咱們的項目都沒有使用這兩樣東西，因此足夠使用了。最重要的是，老闆說我最近的工做效率提升了～