我在cron作业中使用mysqldump来备份超过200万行的数据库.
它创建一个文本文件,可用于从命令行恢复数据记录.
我认为在恢复之前编辑转储作为一种更改值和表或列名称的快速方法会很有用- 至少在我了解更多信息并对使用ALTER和UPDATE执行此操作充满信心之前.
编辑大型文本文件并不会让我感到烦恼,但我惊讶地发现,在250兆字节的数据库转储中,只有大约300行.每行都有800k字符长.
是否有另一种生成转储的方法,可以更好地控制线路长度?
或者我应该使用sed或Perl等工具对转储进行后处理?
这已被问过几次,但我无法找到解决问题的方法.基本上当使用mysqldump(MySQL Workbench管理工具的内置工具)时,当我使用扩展插入转储数据库时,我会获得大量的长行数据.我明白为什么会这样做,因为它通过将数据作为一个命令(特别是在InnoDB上)插入来加速插入,但格式化使得真正难以实际查看转储文件中的数据,或者使用diff工具比较两个文件如果你将它们存储在版本控制等等.在我的情况下,我将它们存储在版本控制中,因为我们使用转储文件来跟踪我们的集成测试数据库.
现在我知道我可以关闭扩展插入,所以每行会有一个插入,这是有效的,但是每次使用转储文件进行恢复时它都会变慢.
我的核心问题是,在我转储文件时我们曾经使用过的OLD工具(MySQL管理员),它基本上做了同样的事情,但是它的格式是INSERT语句每行放一个插入,同时仍然进行批量插入.所以不是这样的:
INSERT INTO `coupon_gv_customer` (`customer_id`,`amount`) VALUES (887,'0.0000'),191607,'1.0300');
Run Code Online (Sandbox Code Playgroud)
你得到这个:
INSERT INTO `coupon_gv_customer` (`customer_id`,`amount`) VALUES
(887,'0.0000'),
(191607,'1.0300');
Run Code Online (Sandbox Code Playgroud)
无论我尝试什么选项,似乎没有任何方法可以获得这样的转储,这真的是两全其美.是的,它需要更多的空间,但在需要人来阅读文件的情况下,它会使它变得更有用.
我错过了什么,有一种方法可以使用MySQLDump,或者我们都倒退了,旧的(现已弃用的)MySQL管理员工具中的这个功能不再可用?