我使用crontab，mysqldump备份一个小的sql数据库，并将其检入源代码控制。次要数据库更改通常会导致源代码管理日志中出现不可读的差异。这让人们感到沮丧，然后提交审核＆＃34;管道
原因是极长的线条，其中隐藏着微小的变化。例如，这是一个基于Wordpress数据库的示例：
INSERT INTO `site_options` (`option_id`, `option_name`, `option_value`, `autoload`) VALUES (1, 'siteurl', 'http://example.org/', 'yes'),(2, 'home', 'http://example.org/', 'yes'),(3, 'blogname', 'Example', 'yes'),(4, 'blogdescription', 'Awesome Description', 'yes'),(5, 'users_can_register', '0', 'yes'),(6, 'admin_email', 'alice@example.org', 'yes'),(7, 'start_of_week', '1', 'yes'),(8, 'use_balanceTags', '0', 'yes'),(9, 'use_smilies', '1', 'yes'),(10, 'require_name_email', '', 'yes'),(11, 'comments_notify', '', 'yes'), (12, 'posts_per_rss', '10', 'yes'),(13, 'rss_use_excerpt', '0', 'yes'), ...
我已经有成千上万个字符/行的插入，可能会在每个元素/行之后使用换行符进行格式化。
注意这些我认为：＆＃34;是的，我敢打赌如果通过某种漂亮的打印机运行这种差异会更加简洁。＆＃34;一个随意的搜索没有打开mysqldump的开关，或者开源sql漂亮打印机的明显选择。然后我想＆＃34; Gosh有人必须已经解决了这个问题。＆＃34;
建议？
答案 0 :(得分：0)
这个问题是How to deal with enormous line lengths created by mysqldump的重复，我们在其中了解到，如果不修补mysqldump或使用其他工具进行后期处理，就无法修复此问题。哪个需要理解sql语法以使其正确。