快速备份和还原 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 十倍了。不过这个方法有一个缺点，由于是经过异构数据库来进行数据备份和还原，因此视图和存储过程将不会被保留。不过咱们的项目都没有使用这两样东西，因此足够使用了。最重要的是，老板说我最近的工做效率提升了～