一直使用 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 十倍了。不過這個方法有一個缺點，因為是通過異構數據庫來進行數據備份和還原，所以視圖和存儲過程將不會被保留。不過我們的項目都沒有使用這兩樣東西，所以足夠使用了。最重要的是，老板說我最近的工作效率提高了～