mysql数据备份的一个坑

最近在升级程序时,要先对数据库进行备份。首先使用的是navicat的备份功能,但是数据备份完,我又新建了一个空的数据库,结果数据还原进去后,发现user表一条记录也没有,所以navicat肯定是不能用了。
然后想到mysql自带一个mysqldump命令,可以用它来备份数据库,命令如下:

mysqldump -uroot -p xxx > /x/x/bak.sql

其中xxx为要备份的数据库的名字,后面为备份文件的路径。备份完后,看了看bak.sql,里面是有我的数据的。然后我用新的空库进行还原,命令如下

mysqldump -uroot -p xxx < /x/x/bak.sql

还原过程中虽然没报错,但是数据库里没东西。
网上查了下,可以用mysql连接数据库,然后使用source命令进行还原。

mysql -uroot -p
use xxx
source /x/x/bak.sql

然后看了下数据库,还原成功了。这时候我觉得数据库备份应该没问题了,但这时坑其实已经开始了。
我先把原库删除,然后部署了程序,最后又使用备份文件还原了数据库。这时我进入程序中才发现,
我的数据大部分都没有了
WTF!!!
打开我的备份文件,突然发现,有一个表所有记录,居然是用一条insert语句插入的
到这里,虽然我不敢百分百肯定,但我知道肯定坑就是在这了。为了提高数据的存储效率,所以mysql默认使用单条insert语句来执行整张表的数据的,但是对于数据量比较多的表,insert语句就会变得非常长,而mysql它自己又无法生成那么长insert语句,所以我的部分数据就没被备份。
查了下,可以使用--skip-extended-insert--extended-insert=false参数来生成多条的insert语句,例如:

mysqldump -uroot -p --skip-extended-insert xxx > /x/x/bak.sql

经过测试,此方法生成的备份文件虽然稍大些,但是在还原速度和数据安全上都是没问题的(最开始生成的备份文件,还原需要20分钟,而此方法生成的备份文件,还原需要20秒钟)。
以上所有测试都是基于mysql5.5 windows 版本进行测试的,最新版的mysql未进行测试。我还从网上看到有人鼓励使用单条insert语句来进行数据库的备份,还进行了测试,说还原时速度快。但我感觉他像在放屁。
谨记。

你可能感兴趣的:(杂项,mysql,数据库,数据备份)