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语句来进行数据库的备份，还进行了测试，说还原时速度快。但我感觉他像在放屁。
谨记。